The Three-Renderer Rule: Why Your Video Pipeline Needs a Single Source of Truth

Building a video generation pipeline often starts with a simple requirement: "We need to generate a video from this data." Most teams reach for FFmpeg, write a shell script, and call it a day. But as soon as you need a live preview, a collaborative editor, or a way to export that same video in the browser to save on server costs, the "scripting" approach falls apart.

You end up maintaining three different versions of the same video: a shell script for the server, a Canvas-based hack for the preview, and a complex WebCodecs implementation for the browser export. This is the death of maintainability.

Enter the Three-Renderer Rule.

What is the Three-Renderer Rule?

The Three-Renderer Rule states that for a programmatic video toolkit to be production-ready, it must support three distinct rendering environments from a single, portable source of truth.

1. Headless Server Rendering: For batch processing and background jobs (Node.js).
2. In-Browser Export: For client-side rendering to eliminate server egress and compute costs.
3. Frame-Accurate Live Preview: For real-time editing and instant feedback loops.

If your stack doesn't support all three with the exact same code, you aren't building a pipeline—you're building a legacy system.

The Single Source of Truth: VideoJSON

At the heart of the Three-Renderer Rule is the concept of a "diffable" video. In VideoFlow, we don't treat videos as binary blobs or opaque scripts. We treat them as VideoJSON.

VideoJSON is a portable, declarative description of every layer, animation, transition, and effect in your video. Because it's just JSON, it can be stored in a database, version-controlled in Git, and most importantly, consumed by any VideoFlow renderer.

Whether you are using @videoflow/renderer-server on a Lambda function or @videoflow/renderer-browser in a user's Chrome tab, the output is guaranteed to be frame-identical.

Implementing the Rule with VideoFlow

VideoFlow was built from the ground up to satisfy the Three-Renderer Rule. Here is how you define a video once and render it anywhere using the @videoflow/core builder API:

import VideoFlow from '@videoflow/core';

const $ = new VideoFlow({
  width: 1080,
  height: 1920,
  fps: 30,
});

// Add a background with a GLSL effect
const bg = $.addImage({ 
  source: 'https://example.com/bg.jpg', 
  fit: 'cover',
  effects: [{ effect: 'bloom', params: { intensity: 0.8 } }]
});

// Add text with a transition
$.addText({ 
  text: 'The Three-Renderer Rule', 
  fontSize: 6, 
  color: '#FF5A1F' 
}, {
  transitionIn: { transition: 'typewriter', duration: '1s' }
});

// Compile to the portable source of truth
const videoJson = await $.compile();

1. The Server Renderer

When you need to render at scale without worrying about user hardware, you pipe that JSON into @videoflow/renderer-server. It uses headless Chromium to render frames and WebCodecs to mux them into an MP4—no FFmpeg installation required on your host.

2. The Browser Renderer

To save on costs, you can send that same videoJson to the client. Using @videoflow/renderer-browser, the user's own machine handles the rendering. This is perfect for "Export to MP4" buttons in SaaS dashboards.

3. The DOM Renderer

For the ultimate developer experience, @videoflow/renderer-dom provides a 60fps live preview. It doesn't generate a video file; it renders the layers directly to the DOM and Canvas, allowing for frame-accurate seeking and real-time property updates.

Why This Matters for Engineering Teams

By following the Three-Renderer Rule, you eliminate the "it works on my machine" problem for video.

• Consistency: A transition like glitchResolve looks exactly the same in the preview as it does in the final MP4.
• Efficiency: Developers can build and debug using the live preview in the Playground, then deploy the exact same logic to a production server.
• Flexibility: You can start with server-side rendering and migrate to browser-side rendering as your user base grows, without rewriting a single line of your video logic.

Conclusion

Stop treating video as a side-effect of a shell script. Treat it as code. By adopting a single source of truth like VideoJSON and ensuring your stack supports the Three-Renderer Rule, you build video pipelines that are as maintainable and scalable as the rest of your web app.

Ready to see the rule in action? Head over to our Docs to explore the renderers, or jump into the Playground to start building your first VideoJSON project.

If you're coming from other tools, check out our VideoFlow vs Remotion comparison to see how our architecture differs.