March 14, 2026
When your podcast nukes your website
Offloading FFmpeg with Cloudflare
Podcaster moves audio crunch to Cloudflare — comments explode over cost, Fly vs AWS vs WASM
TLDR: After a long episode crashed his site, Kent moved audio processing off the main server to Cloudflare so publishing no longer slows everything down. Commenters are split between keeping it on Fly with a wake‑up worker, going cheaper with AWS/Hetzner, or pushing work to the browser via ffmpeg.wasm.
Kent C. Dodds hit publish on a marathon podcast and accidentally drop-kicked his own site. The in-house audio mashup (using FFmpeg, a popular free audio/video tool) ran on his main server and sent CPU usage into the stratosphere. So he moved the heavy lifting to Cloudflare Queues and Workers/Containers, letting a background machine stitch audio and call back when done. Translation: the website stops freezing while the podcast gets mixed. Clean, neat… and instantly controversial.
The comments came in hot. One camp shouted “keep it simple and cheap”: Doohickey-d says you can do all of this on Fly with an on-demand beefy box that wakes up, crunches, shuts down — no Cloudflare container needed. The frugal brigade, led by detuks, calls Cloudflare Containers the “most expensive” way to blend audio, preaching AWS spot instances and Hetzner for bargain-processing. Then a curveball: thadk floats ffmpeg.wasm, a browser-based approach that could process audio before upload — cue jokes about offloading the work to your users’ laptops. Meanwhile, anesxvito cheers the move as a textbook “push the heavy stuff elsewhere” win. And in the comic relief corner, DanielHB casually reveals a one-line FFmpeg baby-cam hack that had readers asking if FFmpeg can also babysit their servers. Verdict? Kent’s fix works, but the crowd is split between convenience, cost, and “you could’ve done this five other ways.”
Key Points
- •FFmpeg previously ran inline on the Fly.io primary instance during podcast publish, handling stitching, trimming, loudness normalization, and bumpers.
- •A long recording on March 6, 2026 caused CPU saturation (400–500% load) and throttling on the primary machine, degrading site performance.
- •The primary instance handles all writes; read replicas are read-only, making the primary a bottleneck for inline processing.
- •The new design enqueues jobs to Cloudflare Queues and returns immediately, removing blocking from the app server.
- •Cloudflare Workers dispatch jobs to Containers, which pull from R2, run FFmpeg, upload results to R2, and post a signed callback to update the app.