How We Moved Video Rendering From the Server to the Browser

The Problem With Server-Side Video Rendering If you have ever built a video editing tool, you know the pain of server-side rendering. Heavy FFmpeg processes, GPU provisioning, cold starts, job queues, and infrastructure costs that scale linearly with every export. For ClipCrafter -- an open-source app that turns long videos into short, captioned clips -- this was becoming unsustainable. Our previous architecture relied on Remotion running inside a Docker container on Railway. Every time a user exported a clip, a serverless function would spin up, pull in Chromium, render frames, and stitch them with FFmpeg. It worked, but it was slow, expensive, and fragile. So we ripped it all out. Enter framewebworker In PR #214, we replaced the entire backend rendering pipeline with framewebworker -- a library that renders video frames directly in the browser using Web Workers and the WebCodecs API. The idea is simple: instead of shipping video data to a server, encode it right where the user alread