# FFmpeg 9 in the cloud, run it exactly as local

Canonical: https://rendobar.com/blog/ffmpeg-9-cloud-api/
Author: Abdelrahman Essawy
Published: 2026-10-22

---

## Key takeaways

- Rendobar runs FFmpeg 9.0. You send the exact command you would run on your own machine, and it runs as written in the cloud.
- Serverless functions cannot run the FFmpeg binary, and a Lambda layer caps you on run time and gives you no GPU. An API call has neither limit.
- Any input reaches ffmpeg under the name you reference: audio, subtitles, concat lists, images or data. Every file the command writes comes back, named as you wrote it.
- A failed command returns ffmpeg's own first error line, so you debug against ffmpeg, not against a wrapper.

Rendobar runs the FFmpeg command you would run on your own machine, on FFmpeg 9.0, in the cloud. You send your argv and your input URLs, the job runs the command as written, and you get back every file it produces as a hosted URL. There is no server to manage, no binary to package, and no GPU to rent.

_A terminal running an unchanged ffmpeg command on FFmpeg 9.0, with a sha256 on the returned file_

FFmpeg 9.0 "Lei" landed in August 2026 with native animated WebP decoding, more Vulkan and AMD AMF hardware paths, a `transpose_cuda` filter that keeps rotation on the GPU, and an ONNX backend for running models inside a filter graph. The usual way to get a new FFmpeg is to install it everywhere your code runs and keep it current. Rendobar runs 9.0 for you, on every job, and reports the exact build in each job's `ffmpegVersion`.

## Why not just run FFmpeg in a serverless function

A plain serverless function cannot execute the FFmpeg binary. The common fix is a Lambda layer that ships `ffmpeg` alongside your code, and it works until a job runs longer than the function's timeout or needs a GPU the function does not have. Calling an FFmpeg API from the function removes both limits: the function makes one HTTP call, and the job runs on infrastructure built for it.

| | Install it yourself | Lambda layer | Rendobar FFmpeg API |
|---|---|---|---|
| Keep 9.0 current | you patch every host | you repackage the layer | always 9.0 |
| Long jobs | fine | capped at the timeout | bounded by your plan, not a function |
| GPU | you provision it | none | NVENC available |
| Your command | runs as written | runs as written | runs as written |

## Send the command you already have

You do not learn a new format. You send the argv you would type locally, and reference each input by name.

```bash
curl -X POST https://api.rendobar.com/jobs \
  -H "Authorization: Bearer $RENDOBAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "ffmpeg",
    "inputs": { "source": "https://example.com/clip.mp4" },
    "params": { "command": "ffmpeg -i source -vf scale=1280:-2 -c:v libx264 -crf 20 out.mp4" }
  }'
```

The output keeps the name you gave it, `out.mp4`, and comes back with its `sha256`. An input can be audio, a subtitle file, a concat list, an image or a data file, and it reaches ffmpeg under the name you referenced. A command that only measures, like `-af volumedetect -f null -`, returns ffmpeg's log in `output.data.log` rather than a file. A command that fails reports [ffmpeg's own first error line](/blog/ffmpeg-errors-explained/), so you debug against ffmpeg, not against a wrapper.

Here is a real analysis job, and the top of what it returned:

```text
$ ffmpeg -i source -af volumedetect -f null -

ffmpeg version n9.0.2  Copyright (c) 2000-2026 the FFmpeg developers
...
[Parsed_volumedetect_0] mean_volume: -21.3 dB
[Parsed_volumedetect_0] max_volume: -5.9 dB
```

## Start

The FFmpeg API is on every plan, and the signup credit covers real jobs so you can run your own command before you commit. Point your existing command at it and read the output URL back.

- [FFmpeg API](https://rendobar.com/ffmpeg/)
- [FFmpeg job docs](https://rendobar.com/docs/jobs/ffmpeg)
- [Pricing](https://rendobar.com/pricing/)