Lambda can run FFmpeg. This is what it costs you, measured, and the one HTTPS request that skips all of it.
// handler.ts (AWS Lambda, Node.js runtime)import { createClient } from "@rendobar/sdk";
const rb = createClient({ apiKey: process.env.RENDOBAR_API_KEY! });
export const handler = async (event: { videoUrl: string }) => { // Offload the command. No layer, no /tmp, no 15-minute ceiling. const job = await rb.jobs.create({ type: "ffmpeg", params: { command: `ffmpeg -i ${event.videoUrl} -c:v libvpx-vp9 out.webm` }, });
// Returns in milliseconds, so the function bills for milliseconds. return { statusCode: 202, body: JSON.stringify({ jobId: job.id }) };};Unlike a Worker isolate, Lambda will happily execute a native binary. The problem is not whether FFmpeg runs. It is the three quotas it runs into.
The static ffmpeg binary unpacks to 140 MB, and Lambda counts 250 MB unzipped across every layer. That is 56% of the budget for one file. Add ffprobe at 139.8 MB and you are over the cap with none of your own code deployed.
Then CPU. Lambda sells it through memory, at 1,769 MB per vCPU. We measured a real VP9 transcode holding 2.2 cores while touching only 387 MB of RAM. Renting those cores means provisioning about 3,892 MB, around 10.1 times the memory the work needs.
Then the clock. 15 minutes is a hard quota, so a long encode has to be split into chunks and reassembled, and that machinery is yours to build. An offloaded job gets 9 hours on Pro and 1 hour on Free, in one job with nothing to stitch.
// handler.ts (FFmpeg from a Lambda layer)import { execFile } from "node:child_process";
// The binary ships in a layer at /opt/bin/ffmpeg.// Measured on the BtbN linux64-gpl build: ffmpeg is 140 MB// unpacked, against a 250 MB unzipped cap that counts every// layer. Add ffprobe (139.8 MB) and you are at 279.8 MB,// over the cap before any of your own code.export const handler = async (event: { key: string }) => { // The video cannot arrive in the invoke: 6 MB cap on // request and response. So it round-trips through S3 first. await downloadFromS3(event.key, "/tmp/in.mp4");
await execFile("/opt/bin/ffmpeg", [ "-i", "/tmp/in.mp4", "-c:v", "libvpx-vp9", "/tmp/out.webm", ]);
// The function is billed for the whole transcode, and dies at // 15 minutes no matter how much is left to encode. return uploadToS3("/tmp/out.webm");};H.264 to VP9 with libvpx-vp9 and libopus, submitted to the Rendobar API in us-east-1 on 20 August 2026. These are the numbers the rest of this page argues from.
Binary sizes on this page were measured the same day against the BtbN linux64-gpl build. Lambda quotas are AWS's published figures.
Your handler calls rb.jobs.create with type "ffmpeg" and your command string. It is one HTTPS request, so the function returns in milliseconds and bills for milliseconds.
Rendobar runs the exact FFmpeg command in a container built for media work. No layer to assemble, no 250 MB budget to fit inside, and CPU that is not rationed by how much memory you rented.
The output lands in R2 with no egress fee on the download, and the job result carries its URL. No S3 round trip to write yourself.
Rendobar POSTs the finished job to the endpoint you registered. Nothing waits, so nothing meets the 15-minute ceiling.
| Approach | Runs? | What it costs you |
|---|---|---|
| Static binary in a layer | Yes | Runs, but ffmpeg alone is 140 MB of the 250 MB unzipped budget |
| Container image | Yes | 10 GB of room, and you own the image, the build and the cold start |
| AWS Elemental MediaConvert | Yes | Managed transcoding, though it does not take arbitrary FFmpeg commands |
| Rendobar API (offload) | Yes | One HTTPS call, no binary, and 9 hours per job instead of 15 minutes |
Every row here works. The column that matters is the third one.
Yes. Ship the binary in a layer or as a container image and it runs. The question is what it costs you, and the answer is a 250 MB package budget, a hard 15-minute ceiling, and CPU that you can only buy by renting memory.
The BtbN linux64-gpl static build unpacks to 140 MB for ffmpeg and 139.8 MB for ffprobe, measured on 2026-08-20. Lambda counts 250 MB unzipped across every layer, so ffmpeg alone takes 56% of the budget and the pair does not fit. Slimmer custom builds exist if you drop codecs you do not need.
Lambda allocates CPU in proportion to memory, at 1769 MB per vCPU. A Rendobar job encoding H.264 to VP9 held 2.2 cores for 6.1 seconds while using 387 MB of RAM. Buying those cores on Lambda means provisioning about 3,892 MB, roughly 10.1 times the memory the work actually touches.
The invocation is killed. 15 minutes is a hard quota, not a default you can raise, so long videos need chunking and reassembly that you build and maintain. Offloaded jobs are not on that clock: the per-job budget is 1 hour on Free and 9 hours on Pro, so a feature-length encode finishes in one job.
No. A synchronous invoke caps request and response at 6 MB each, which almost no real video clears. The file goes through S3 or a presigned URL either way.
Jobs are billed by compute time. The VP9 transcode measured on this page cost $0.0071 and finished 22.3 seconds after submission. Every account starts with $5 in free credits and no credit card.
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 250 MB budget to fit inside.