React Video Editor now has a managed SDK
A founder's note on how React Video Editor evolved from a full source code template into a managed SDK, and why that shift happened.
Sam
Creator of RVE
When I first started React Video Editor, there was no SDK. There was only what is now called RVE Pro: a full Next.js source code template for teams that wanted complete ownership and flexibility from day one. The goal was simple: help companies skip months of rebuilding the same core editor infrastructure over and over again.
That meant timelines, playback, rendering, upload pipelines, media handling, browser quirks, exporting, synchronization, and large-file workflows. For many teams, this worked really well. They wanted deep control from the beginning and needed to shape the editor around their own workflows, so the source-template model was the right fit.
Over time, though, one pattern kept appearing. When customers customized the codebase, it became super hard to stay aligned with ongoing improvements. Upgrades got painful, internal abstractions drifted, and teams ended up maintaining large parts of the editor themselves.
Key takeaways
- RVE Pro solved an important early problem: teams could launch with full ownership and control.
- As products scaled, deep customization made upgrades and long-term maintenance much harder.
- The SDK was created to keep flexibility while reducing long-term integration friction.
Why the SDK Happened
The SDK came from one simple realization: most companies did not actually want to maintain editor infrastructure long term. They wanted to build their product.
We were now solving browser rendering limitations, large media pipelines, Lambda rendering, AI workflows, timeline virtualization, playback optimization, upload systems, media processing, browser storage limits, WebCodecs behavior, collaboration patterns, and the reality of scaling rendering infrastructure.
While some teams still wanted full ownership of every layer, many others increasingly wanted a cleaner integration path that did not involve maintaining a heavily forked codebase for years. That is where the SDK came from.
what changed
The default path moved from source ownership to managed integration
RVE Pro is still available for teams that need full source-level control, but the SDK became the default because most product teams wanted faster adoption, easier upgrades, and less infrastructure ownership.
Instead of shipping a large application template that customers deeply modify, the SDK model is simpler:
- install through npm
- integrate directly into your app
- stay aligned with platform improvements
- avoid painful long-term version drift
This lets us improve the platform centrally while making upgrades and integration significantly easier for customers.
Where Things Are Today
Today, most development happens around the SDK architecture. A lot of the newer rendering infrastructure, timeline improvements, AI workflows, scalability work, and long-term platform direction now lands in the SDK first. That shift happened naturally from working closely with product teams and seeing where maintaining heavily customized forks became difficult over time.
Most teams now start with the SDK because it gives them a cleaner long-term path while still moving quickly. For larger enterprise teams, though, things often go deeper than a standard SDK integration. Some companies need tighter internal integrations, some need custom infrastructure, some want deeper architectural access, and some want direct collaboration with us around roadmap, rendering pipelines, workflows, or internal tooling.
That is increasingly where we spend a lot of our time today. So while RVE Pro is still available for teams that specifically want the original full-template approach, a lot of newer enterprise work now happens around the SDK itself, including deeper integration support, customization work, and source-level access where needed.
What We Learned
One of the biggest lessons from building React Video Editor is this: building a modern web video editor is hard, and maintaining one long term is even harder, especially once you operate at production scale across browsers, rendering environments, infrastructure layers, and evolving APIs.
A lot of the architectural direction behind the SDK came directly from seeing those pain points repeatedly across customer projects. The SDK was not built to remove flexibility. It was built to reduce long-term friction.
The Bigger Vision
Long term, the goal is bigger than "template vs SDK." The vision is building infrastructure for modern video products on the web.
Sometimes that looks like:
- video editing SDKs
- rendering infrastructure
- AI-assisted workflows
- media processing pipelines
- automation systems
- collaborative tooling
- browser rendering infrastructure
- playback systems
A lot of this direction has been shaped directly by customers building real production products with React Video Editor over the last few years. We are still early, but the SDK exists because we listened closely to where teams struggled most, especially when the excitement of shipping turned into the reality of maintaining video infrastructure long term.
Next step
Ready to evaluate your integration path?
Start with the managed SDK docs, or explore Core (Pro) docs if you need deeper source-level control.




