A synchronous function gets 60 seconds and at most 2 vCPU. This is the one request that steps around both.
// netlify/functions/transcode.mtsimport { createClient } from "@rendobar/sdk";
const rb = createClient({ apiKey: Netlify.env.get("RENDOBAR_API_KEY")! });
export default async (req: Request) => { const { videoUrl } = await req.json();
// One HTTPS call. Returns in milliseconds, so the 60s // synchronous budget is never in play. const job = await rb.jobs.create({ type: "ffmpeg", params: { command: `ffmpeg -i ${videoUrl} -c:v libvpx-vp9 out.webm` }, });
return Response.json({ jobId: job.id }, { status: 202 });};
export const config = { path: "/transcode", method: "POST" };Netlify Functions run on AWS Lambda underneath, so a bundled FFmpeg binary does execute. What stops a transcode is not the binary. It is the clock and the CPU cap, and you cannot raise either.
A synchronous function gets 60 seconds. Netlify lists it as not configurable, on every plan. A background function stretches that to 15 minutes, and in exchange it answers 202 and never returns a result, so the storage write and the notification become yours to build.
The harder ceiling is CPU. The vcpu setting tops out at 2, which is what the 4096 MB memory maximum buys. We measured a real VP9 encode holding 2.2 cores with 8 available. FFmpeg takes what it is given, so the same encode still finishes on 2 vCPU. It finishes slower, which is the problem when the budget is counted in seconds.
// netlify/functions/transcode.mts (encode in the function)import { execFile } from "node:child_process";
export default async (req: Request) => { // The video cannot arrive in the request: 6 MB buffered, // and base64 overhead makes that about 4.5 MB of // real binary. So it round-trips through storage first. await downloadToTmp(await req.json());
// Two ceilings, neither configurable: // 60s synchronous budget, and a 2 vCPU cap // at the top plan. A measured VP9 encode spread across 2.2 cores // when 8 were free, so here it runs, and it runs slower. await execFile("/var/task/bin/ffmpeg", [ "-i", "/tmp/in.mp4", "-c:v", "libvpx-vp9", "/tmp/out.webm", ]);
return new Response("...if it ever gets here");};H.264 to VP9 with libvpx-vp9 and libopus, submitted to the Rendobar API on 20 August 2026. The Netlify column is their published maximum, not a default.
| What the job needed | Measured | Netlify maximum |
|---|---|---|
| CPU held through the encode | 2.2 cores | 2 vCPU |
| Memory touched | 387 MB | 4,096 MB |
| Time from submit to result | 22.3s | 60s synchronous |
| Cost | $0.0071 | Billed by size and duration |
The CPU row is a comparison, not a requirement. FFmpeg scales to the cores it is handed, so fewer cores means a longer encode rather than a failure. The row that actually decides this is the clock.
Your function calls rb.jobs.create with type "ffmpeg" and your command string. It returns in milliseconds, so the 60 second synchronous budget is never close.
Rendobar runs the exact FFmpeg command on hardware sized for media work rather than capped at 2 vCPU. The encode we measured spread across 2.2 cores with 8 available, and more cores is what turns a long encode back into a short one.
The output lands in R2 with no egress fee on the download, and the job result carries its URL. Nothing has to squeeze through a 6 MB response.
Rendobar POSTs the finished job to the endpoint you registered. This is the delivery step a background function would leave you to build, since a background invocation answers 202 and never returns a result.
| Approach | Fits a real encode? | Why |
|---|---|---|
| Encode in a synchronous function | No | 60s is the whole budget, and it is not configurable |
| Encode in a background function | Yes | Up to 15 minutes, but you build the result delivery yourself |
| Raise memory to the maximum | No | 4096 MB buys 2 vCPU, which encodes slower, not longer than 60s |
| Rendobar API (offload) | Yes | One HTTPS call, 9 hours per job, result delivered on a webhook |
For anything short, yes. Netlify Functions run on AWS Lambda underneath, so a bundled binary executes. The limit that bites first is time: a synchronous function gets 60 seconds and that number is not configurable on any plan.
The vcpu setting accepts 0.5 to 2, where 2 maps to the 4096 MB memory maximum. That is the ceiling on Pro and Enterprise alike. For comparison, a Rendobar job encoding H.264 to VP9 spread across 2.2 cores with 8 available. FFmpeg uses what it is given, so on 2 vCPU the same encode still finishes, it just takes longer, and the 60 second budget is what it runs into.
Partly. They raise the budget to 15 minutes, which covers more encodes. They also answer 202 immediately and never return a result, so you still have to build the storage write, the status record and the notification. That is the offload pattern, assembled by hand, and still capped at 2 vCPU.
Not usually. Buffered requests and responses cap at 6 MB, and binary payloads are base64 encoded, which adds roughly 30% and leaves about 4.5 MB of real file. Background invocations are much tighter still at 256 KB.
It is cut off at the limit, and a partial output is not a usable video. Offloaded jobs run on a per-job budget of 1 hour on Free and 9 hours on Pro, so a long encode finishes in one job instead of being chunked and stitched.
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 60 second budget.