How to Run FFmpeg in the Cloud: VM, Docker, Serverless or API

There are four ways to run FFmpeg in the cloud: on a virtual machine, in a container, in a serverless function, or through an FFmpeg API. They differ in how much you operate yourself and in the limits you will hit — time, memory, disk and request size.

This guide compares the four with the published limits of each platform, so you can choose before you build. If you already have the command, the FFmpeg cheat sheet shows the common ones.

Summary

Option 1: A virtual machine

Start a VM (EC2, Compute Engine, a Hetzner or DigitalOcean server), install FFmpeg, and run your commands there. Usually you add a job queue so that web requests do not wait for encodes.

Pros

• Full control: any FFmpeg build, any codec, any flags, no time limit.
• A fixed monthly cost that is easy to predict at a steady load.

Cons

• You operate everything: OS updates, the FFmpeg build, the queue, retries, disk cleanup and monitoring.
• One machine is a bottleneck. A long 4K encode blocks the jobs behind it until you add workers and autoscaling.
• You pay for the machine when it is idle.

Pick a VM when the load is steady, the team is comfortable with servers, and you need something no hosted service gives you.

Option 2: A container

Put FFmpeg in a Docker image and run it on a container platform: AWS ECS or Fargate, Google Cloud Run, Kubernetes, or Cloudflare Containers. The platform starts and stops instances for you.

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends ffmpeg ca-certificates \
  && rm -rf /var/lib/apt/lists/*
COPY worker /usr/local/bin/worker
CMD ["worker"]

Pros

• The same image runs on your laptop, in CI and in production.
• Scaling to zero is possible on some platforms, so idle cost is low.

Cons

• You still build the job system: a queue, a worker that pulls jobs, retries, timeouts, and a place to store inputs and outputs.
• Each platform has its own request timeouts and instance sizes, so a long encode can need a background job type in place of an HTTP request.
• Media images are large, which slows cold starts.

Pick containers when your team already runs them and wants FFmpeg next to the rest of the stack. A Cloudflare Worker can start a Container and send it work, which is one way to run the native binary from a Workers app.

For a full comparison of this option with an API, see self-hosted FFmpeg in Docker vs. a hosted FFmpeg API.

Option 3: A serverless function

Package a static FFmpeg binary with an AWS Lambda function (as a layer or a container image) or a Vercel Function, and call it per job. This works well for short jobs on small files. The limits decide everything else:

Limits from each platform’s docs, checked on 15 October 2026.

What this means for video:

• Request bodies are small. You cannot post a video to a Lambda or Vercel function. Upload it to object storage first and pass a URL.
• Run time is finite. A 15-minute Lambda limit is fine for a thumbnail and tight for a long 1080p re-encode. Long jobs need to be split into segments and joined again.
• Disk is temporary. On Lambda, the input and output must both fit in /tmp unless FFmpeg streams them.
• Workers cannot run the native binary. Workers run JavaScript and WebAssembly in isolates with 128 MB of memory. A WebAssembly build of FFmpeg can do small jobs; real transcodes need a container.
• Bundle size matters. Vercel’s standard limit is 250 MB uncompressed, and a full static FFmpeg build uses a large part of it.

Pick serverless when the jobs are short, the files are small, and you already deploy functions there.

Platform guides with setup steps and fixes: FFmpeg on AWS Lambda · FFmpeg on Cloudflare Workers · FFmpeg on Vercel

Option 4: An FFmpeg API

An FFmpeg API (also called FFmpeg as a service) runs FFmpeg on its own machines. You send a job and get the output back. There is no binary to package and no queue to build.

With Xora, the job is the same arguments you run locally, as a JSON array:

curl -X POST https://api.xora.sh/v1/jobs \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "ffmpeg",
    "input_files": { "in_1": "https://example.com/input.mov" },
    "output_files": { "out_1": "output.mp4" },
    "ffmpeg": {
      "args": ["-i", "{{in_1}}", "-c:v", "libx264", "-crf", "23", "-c:a", "aac", "{{out_1}}"]
    }
  }'

The response is { "id": "…", "state": "queued" }. Poll GET /v1/jobs/{id} until the state is completed, failed, rejected or cancelled, or pass webhookUrl to get a callback. A completed job has a signed URL for the output. On paid plans, Xora can write outputs straight into your own Cloudflare R2 bucket.

Pros

• Nothing to operate on the media side: no binary, no queue, no worker fleet, no disk cleanup.
• Your serverless function or n8n workflow only sends a small JSON request, so its limits stop being a problem.
• AI agents can run the jobs too, through an MCP server.
• Recipes for common jobs, such as compress, trim and thumbnail, if you do not want to write flags.

Cons

• A per-job cost. Xora bills credits for machine time and output size; see pricing.
• Inputs must be reachable by the API: a public URL, a presigned URL, or a direct upload.
• Plan limits on input size and concurrent jobs. The Free plan allows 250 MB per file; paid plans allow up to 6 GB.

Pick an API when video is a feature of your product and not the product itself, when your code runs somewhere FFmpeg does not fit, or when an agent needs to run the commands.

How to choose

1. Is your load steady and high, and do you have someone to operate servers? A VM or containers can cost less per job.
2. Are your jobs short and your files small, and do you already deploy functions? Serverless can work. Check the limits table above against your largest file.
3. Does your code run on Workers, Vercel, n8n or in an agent sandbox? Send the job to an API and keep only the HTTP call in your code.
4. Do you need it working this week? An API is the shortest path. You can move to your own infrastructure later with the same FFmpeg arguments.

Next steps

• FFmpeg cheat sheet: common commands and the same job as an API call.
• How to run FFmpeg in n8n workflows.
• FFmpeg for AI agents: give Claude, Cursor or your own agent a place to run FFmpeg.
• Quickstart: your first Xora job.

Frequently asked questions

What is the easiest way to run FFmpeg in the cloud?

An FFmpeg API, because there is nothing to install or operate: you send the FFmpeg arguments and an input URL, and you get the output back. A VM or container gives you more control but you run the queue, the scaling and the storage yourself.

Can I run FFmpeg on AWS Lambda?

Yes, with a static FFmpeg binary in a layer or a container image. Check the limits first: a Lambda function runs for at most 15 minutes, has up to 10,240 MB of memory and up to 10,240 MB of /tmp storage, and a synchronous request or response body is at most 6 MB.

Can I run FFmpeg on Cloudflare Workers?

Not the native FFmpeg binary. Workers run JavaScript and WebAssembly in isolates with 128 MB of memory, so only small WebAssembly builds fit. Cloudflare Containers can run the native binary, with a Worker in front.

What is FFmpeg as a service?

A hosted API that runs FFmpeg for you. You send a job with FFmpeg arguments or a named operation, the service runs it on its machines, and it returns the output file. Xora is one example: it takes the FFmpeg arguments as a JSON array and returns a signed URL or writes to your own Cloudflare R2 bucket.