Ten videos a week is a script. Ten thousand a night is an architecture. Programmatic video earns its name at scale — when the pipeline, not a person, is responsible for every frame — and scale is a systems problem: queues, workers, storage, and a growth path that doesn’t require a rewrite at each order of magnitude.
The shape of that architecture, using Meishe’s batch rendering pipeline as the reference (full documentation):
your app → task queue → scheduler → compile/transcode workers → shared storage → deliverySimple on paper. The design decisions that make it survive production are below.
The Core Idea: Submission and Execution Are Separate
The pattern that scales is splitting “what should be rendered” from “what renders it now”:
- Your application submits tasks — a synthesis request carrying the project JSON, output specs, and a source of media to pull from
- A task scheduler owns the queue — receives, manages, and dispatches synthesis and transcode tasks
- Workers render — compile services turn projects into video; transcode services handle format conversion
- Shared storage carries media in and files out — workers read source material and write finished video to the same layer
Why this split matters: your app’s code never changes as the farm grows. The same task-submission call serves a single-server validation deployment and a multi-region cluster. Scaling becomes an infrastructure decision, not an application rewrite.
Stage 1: One Server, Everything On It
Start small, deliberately. Scheduler and worker instances on a single machine:
- Validate the pipeline end to end with real workloads
- Process early production volume at modest concurrency
- Learn your actual per-render cost profile before committing hardware
Multiple service instances can run on that one server for parallelism. This stage answers “does it work” — and in plenty of products, it quietly answers “this is all we need” for months.
Stage 2: More GPUs, Same Server
The first bottleneck is usually render throughput. Before adding machines, add GPUs: NVIDIA cards each driving their own compile/transcode instances, tasks distributed across devices.
Two rules from the docs worth engraving:
- Assign each service instance to a specific GPU — explicit assignment prevents resource overlap and makes capacity predictable
- Check NVIDIA’s codec support matrix before buying — a card’s video encode/decode engine count and supported codecs matter more than memory size for rendering workloads
This stage is the cheapest capacity jump in the whole path: no new servers, no topology change, just density.
Stage 3: Controller Plus Workers
When one server can’t hold the demand, go horizontal: a controller node running the scheduler, multiple worker servers rendering in parallel, NFS or object storage shared between them.
Workers can mix CPU and GPU editions based on their hardware — the fleet absorbs existing machines instead of demanding uniformity. Each worker can itself be a multi-GPU box, so the topology composes: multi-worker, multi-GPU, growing along whichever axis your workload pushes.
Stage 4: Kubernetes
For teams with an existing K8s platform, the whole pipeline containerizes: scheduler, compile services, transcode services as managed workloads — GPU resources, persistent storage, and networking configured through the cluster you already operate. Rendering becomes another service in your fleet, with the same release process and observability as everything else.
What Every Stage Shares
The constants across all four stages:
One task format. The synthesis request your app submits is identical at every scale — that’s what makes stage transitions non-events for your codebase.
Idempotent rendering. Same project JSON in, same video out. Retries are safe; caching is possible; failure recovery is a re-queue, not an investigation.
Observability from day one. Queue depth, per-template render durations, failure rates by task type. The docs’ planning guidance is blunt about it: test representative workloads — real timelines, real resolutions, real codecs — before finalizing any production configuration, because actual capacity depends on timeline complexity, resolutions, and concurrency in ways spec sheets don’t predict.
Planning the Numbers Honestly
Capacity questions have honest answers only against your own workloads. The variables that move them:
- Timeline complexity — three clips and a title render faster than multi-track with effects and transitions
- Output specs — resolution, codec, and bitrate change transcode time materially
- Concurrency profile — a nightly burst saturates differently from a steady all-day stream
- CPU vs GPU editions — the right choice depends on codec requirements and delivery deadlines, not fashion
The method the docs recommend and experience confirms: run your representative workload at each stage before scaling to the next, and let the measured numbers — not vendor promises — size the fleet.
Scale as a Feature
The psychological shift: at small scale, rendering is a task; at scale, rendering is a product feature with an SLA. Teams that design for the four-stage path from the beginning — queue-first architecture, shared storage, workers without state — find that each growth step is an ops ticket instead of a quarter. The server rendering overview walks the full pipeline; the JSON examples show what flows through it.
Start on one server. Grow when the queue tells you to. The architecture should be the least dramatic part of your success.