This is the whole integration. One HTTP request offloads the command and returns right away, so the Worker stays fast and never touches its CPU budget.
// src/index.ts (Cloudflare Worker)import { createClient } from "@rendobar/sdk";
export default { async fetch(req: Request, env: Env) { const { videoUrl } = await req.json(); const rb = createClient({ apiKey: env.RENDOBAR_API_KEY });
// Offload the command, return right away. const job = await rb.jobs.create({ type: "raw.ffmpeg", params: { command: `ffmpeg -i ${videoUrl} -c:v libvpx-vp9 out.webm` }, });
return Response.json({ jobId: job.id }); },};You can't run a native FFmpeg binary inside a Cloudflare Worker. Workers run on a V8 isolate with no disk and no way to spawn a native process, so the ffmpeg binary can't run.
So people reach for ffmpeg.wasm. The core is about 30 MB of WebAssembly, far past the 3 MB free Worker bundle cap, and a real transcode runs out of CPU and memory anyway. The offload version is the snippet at the top of this page.
// src/index.ts (Cloudflare Worker)import { FFmpeg } from "@ffmpeg/ffmpeg";
// @ffmpeg/core is about 30 MB of WebAssembly. A Worker bundle// is capped at 3 MB gzipped (free) / 10 MB (paid), so it won't ship.// There's no disk and no way to spawn a native binary either,// and the CPU limit can't cover a full transcode anyway.export default { async fetch(req: Request) { const ffmpeg = new FFmpeg(); await ffmpeg.load(); // blows the Worker size and CPU budget return new Response("never gets here"); },};Your Worker calls rb.jobs.create with type "raw.ffmpeg" and your command string. It's a single HTTPS request, so the Worker returns in milliseconds and never touches its CPU budget.
Rendobar runs the exact FFmpeg command in an isolated container built for media work. Full codecs, full CPU, none of the V8 isolate limits.
When the command finishes, the output is stored in R2 (no egress fees on the download) and the job result carries its URL. Read it from the webhook, or poll GET /jobs/{id}.
Rendobar POSTs the finished job to the endpoint you registered. The Worker never had to wait, so it never hit the CPU limit.
| Approach | Works in a Worker? | Why |
|---|---|---|
| ffmpeg.wasm in the Worker | No | ~30 MB core blows the 3 MB free bundle cap |
| Spawn the FFmpeg binary | No | No native process to spawn in a V8 isolate |
| Bundle a static binary | No | Workers can't execute native binaries |
| Rendobar API (offload) | Yes | One fetch, the Worker stays tiny |
Workers run in a V8 isolate, not a container. There's no real disk, no way to spawn a native process, and no native executable like FFmpeg to run. Offloading the command keeps the Worker fast and under its CPU budget.
Rendobar skips it for you. The @ffmpeg/core WebAssembly build is around 30 MB, far past the 3 MB free Worker bundle cap, and a real transcode exhausts the Worker's CPU and memory before it finishes.
They can. A Container runs a Docker image with FFmpeg installed, so that path works. You own the Dockerfile, the cold start, and the container billing, though. Offloading to Rendobar is one HTTPS call from the Worker, with no image to build or maintain.
Yes. Your Worker makes one HTTPS call and returns, which costs effectively no CPU time. The 10 ms (free) or 30 second (paid) CPU budget stays untouched. The FFmpeg work runs in a separate sandboxed container.
Register a webhook endpoint once (rb.webhooks.create) and Rendobar POSTs each finished job to it. You can also poll GET /jobs/{id} or subscribe with the realtime SDK.
Jobs are billed by compute time. Every account begins with $5 in free credits and no credit card, so you can run a real transcode before paying anything.
The call is a plain HTTPS request, so the same offload runs from every serverless host. Pick your runtime and follow the guide.
$5 free on signup. No credit card. No binary required.