VideoFlowcodeGitHubTry itCoreRenderersReact Video EditorPlaygroundExamplesDocscodeGitHubTry it
← Back to Blog

The Three-Renderer Rule: Choosing the Right Engine for Your Video Pipeline

July 8, 2026 · By VideoFlowLearn how to choose between browser, server, and live-preview rendering to build a cost-effective and performant programmatic video pipeline.The Three-Renderer Rule: Choosing the Right Engine for Your Video Pipeline

The Three-Renderer Rule: Choosing the Right Engine for Your Video Pipeline

Building a programmatic video pipeline often feels like a series of trade-offs. If you render on the server, you face high infrastructure costs and scaling headaches. If you render in the browser, you struggle with consistency and performance.

The "Three-Renderer Rule" is our answer to this dilemma: a truly portable video pipeline should use the same source code to power live previews, client-side exports, and headless server-side automation. In VideoFlow, this is made possible by the decoupling of your video logic (VideoJSON) from the video rendering engine that executes it.

A technical diagram showing three distinct paths (Browser, Server, DOM) branching from a single JSON source

1. The Browser Renderer: Zero-Cost Client-Side Export

The most efficient way to scale video production is to stop paying for it. By using @videoflow/renderer-browser, you can move the entire rendering and encoding process to the user's local machine.

This renderer leverages the WebCodecs API to encode MP4 files directly in the browser tab. Because it runs in a Web Worker, it doesn't freeze the UI, and it avoids the massive egress costs associated with transferring large video files from a server to a client.

import VideoFlow from '@videoflow/core';
import BrowserRenderer from '@videoflow/renderer-browser';

const $ = new VideoFlow();
$.addText({ text: 'Client-side Export', fontSize: 6 });
$.wait('2s');

const json = await $.compile();
const renderer = new BrowserRenderer();
const blob = await renderer.exportVideo(json);

This is the perfect choice for SaaS tools where users need to "download" their creations, or for social media automation tools where the user is already in the app. You can even test this right now in the VideoFlow Playground.

2. The Server Renderer: Headless Automation at Scale

When you need to generate videos on a schedule or in response to a webhook—without a user present—you need headless video rendering.

The @videoflow/renderer-server package uses Playwright to drive a headless Chromium instance. Unlike traditional solutions that rely heavily on FFmpeg shell commands, VideoFlow renders frames using the same engine as the browser, ensuring byte-for-byte identity between what you see in development and what you get in production.

A stylised server rack representing headless rendering

By default, the server renderer uses a high-performance pipeline that avoids the overhead of per-frame screenshots, making it significantly faster than legacy headless approaches.

import VideoFlow from '@videoflow/core';
import '@videoflow/renderer-server'; // Registers the server renderer

const $ = new VideoFlow();
// ... build your scene ...

await $.renderVideo({
  outputType: 'file',
  output: './automated-report.mp4'
});

For more details on setting up your environment, check out our guide to renderers.

3. The DOM Renderer: Frame-Accurate Live Preview

A video pipeline isn't just about the final export; it's about the developer experience. The @videoflow/renderer-dom is designed specifically for live preview and scrubbing.

It renders your VideoJSON directly into a Shadow DOM element, providing a frame-accurate 60fps preview. This is what powers the React Video Editor, allowing users to drag keyframes and see the results instantly without waiting for a render.

A web browser window representing client-side export

Why Portability Matters

The magic of VideoFlow is that your code doesn't change. You write your video logic once using the VideoFlow Core API, and it compiles to a portable VideoJSON document. This document is the "source of truth" that any of the three official renderers can consume.

This architecture allows you to:

  • Develop in the browser with instant feedback via the DOM renderer.
  • Preview the final export locally using the Browser renderer.
  • Deploy to a fleet of Node.js workers for batch processing with the Server renderer.

If you are currently evaluating Remotion alternatives, this portability is a game-changer. You aren't locked into a specific React runtime or a proprietary rendering cloud.

Getting Started

Ready to build your first pipeline? Head over to our Getting Started guide or explore the source on GitHub. Whether you're building a YouTube Shorts factory or a personalized SaaS recap tool, the three-renderer rule ensures your pipeline is built for the long haul.

VideoFlow

Open-source toolkit for composing videos from code.

Product

CoreRenderersReact Video EditorPlayground

Learn

DocsAPI referenceExamplesvs. Remotionvs. FFmpeg

Project

GitHubLicenseContactTermsPrivacy

From the blog

All posts →Generating Multi-Language Video at Scale: The Localization PlaybookBrowser-Side Video Export: Zero-Server Rendering with WebCodecsCinematic GLSL: Stacking Effects for a Retro VHS Look in VideoFlowCinematic Text: Mastering Typography and Text Effects in VideoFlowHow to Generate Personalized Video Ads from a CSV with TypeScriptThe Git-Flow for Video: Why Your MP4s Should Be Diffable JSONBeyond the Play Button: Building Interactive Video Docs with VideoFlowBeyond the Prompt: Why LLMs Need Portable VideoJSON
© 2026 VideoFlow. Apache-2.0 core.