Content Builder Studio - A render pipeline that ships safely
How we built the render pipeline behind Content Builder Studio: serverless workers that cost nothing while idle, uploads that survive bad phone connections, an automatic quality check with a free re-render, and engine updates that roll out on their own without breaking a single reel in progress.
Part 2 of the Content Builder Studio series. New here? Start with part 1: Relaunch as a reels product.
Project snapshot
Field | Detail |
|---|---|
Project | Content Builder Studio: render pipeline and operations |
Type | Video processing infrastructure · CI/CD · reliability |
Operator | JK DEV, the Netherlands |
Delivery | Built end to end by techlead.fit |
Status | Live in production since 20 October 2026 |
Under the hood | RunPod Serverless (CPU render, GPU transcription) · faster-whisper · Claude · Remotion · FFmpeg 7.1 · Directus 12 · PostgreSQL · S3 · Docker · GitHub Actions · AWS Lightsail |
Quality gate | 116 automated checks on every change; every new engine image renders two test reels before it may go live |
The problem
A reels product lives or dies on one thing: the customer uploads a video and gets a good reel back, every time. Behind that sit a lot of moving parts: large uploads from phones, GPU transcription, an AI edit, video rendering, storage, payments and refunds. Any of them can fail, and a small team cannot watch them all day.
So the pipeline had to be cheap when nobody is using it, fast when someone is, and able to recover from failures on its own.
Architecture
Frontend: Next.js on Vercel.
API: Directus 12 with custom extensions for the app, billing webhooks and the job queue, on a small server behind HTTPS, with managed PostgreSQL and a private storage bucket.
Rendering: one serverless job per reel. The worker claims exactly that reel from the API, renders it, uploads the result and disappears. Transcription runs on a separate GPU endpoint. Nothing runs, and nothing is paid for, while no reel is being made.
The server only runs the API. That keeps it small and cheap, and a heavy render can never slow down the website or checkout.
Uploads from phones
Phone videos are big and mobile connections are not. The upload path was built for the worst case:
Files go directly to storage in parallel parts, not through the API server.
On slow connections the browser can compress the video to 1080p first, using the device's hardware encoder, with time left shown and an option to upload the original instead.
If the bucket is unreachable, uploads fall back to the API server.
Some Android file pickers fail on parallel reads, so the file is read once from front to back, with clear messages for unreadable files and dropped connections.
Failed uploads are reported back from the browser, so problems show up in our data, not in support emails.
Getting the video right
Two details that customers never see, and would immediately notice if they were wrong:
Colour. Early reels looked washed out on Apple devices. The output was tagged without a proper colour matrix. Rendering now converts and tags every reel as BT.709, and HDR phone footage is tone-mapped before editing.
Language and cuts. The spoken language is detected automatically, and every cut is kept inside the source footage, so the editor can never ask for a frame that does not exist.
Quality check and free re-render
Every reel passes an automatic check before the customer sees it: captions or cards covering a face, a frozen picture (measured on the cut, so moving captions cannot hide it), long silences in the speech, loudness and format.
A broken cut is caught early, a few minutes in, and retried or refunded automatically. If the finished reel fails the check, it is still delivered, its page explains what was found in plain words, and the customer can ask for a fresh edit once, for free, without spending a credit.
Updates without downtime
The engine changes often. Each change to the worker builds a new image, and the rollout runs on its own:
Self-test. The new image renders two reels inside itself, one plain and one fully designed. A failing image never goes live.
Quiet moment. The rollout waits until no reel is running or queued.
Switch. Production is pointed at the exact new version, never a moving "latest" tag, and the previous version is recorded for a one-click rollback.
Reels in progress survive anyway. A stopped worker hands its reel back at once, a silent one is rescued by the API within five minutes, and a sweep every minute re-dispatches any reel whose start was lost. Those restarts are counted separately from real failures; only after repeated failures is a reel marked failed and the credit refunded.
The API side follows the same rule: every deploy is health-checked and rolled back automatically if it fails, and both the website and the workers retry through a short API restart instead of failing the customer's action.
Closing the loop
Every reel page has a feedback button with an optional rating, and short service surveys appear after the 1st, 5th, 10th, 20th and 40th reel. Both become tickets on a team page with filters, statuses and an internal note, so product decisions come from what customers actually say.
Outcome
The pipeline costs almost nothing when idle and scales with demand. Rendering a reel costs well under a dollar in AI and compute, problems are caught before the customer notices them, and the team can ship engine improvements several times a day without a maintenance window.
The Content Builder Studio series
The first version: Content Factory & Platform for Dutch startup
Part 1: Relaunch as a reels product
Part 2: A render pipeline that ships safely (this post)
Building something with heavy processing behind it?
Video, AI and large files are where costs and failures hide. We design pipelines that stay cheap at low volume, recover on their own, and let a small team ship every day.
Relevant services: CTO Sprint · Technical Audit · MVP Build