n8n Says "ffmpeg: not found"? Fix the Container or Skip It

Your Execute Command node runs ffmpeg -i input.mp4 ... and n8n hands back /bin/sh: ffmpeg: not found. You SSH into the same server, type ffmpeg -version, and it prints a version banner. Both things are true at once, and that contradiction is the whole bug.

Quick answer: The "n8n ffmpeg not found" error from the Execute Command node means FFmpeg is not installed inside the n8n Docker container. The Execute Command node runs in the container's own shell, so FFmpeg installed on the host machine (or a Windows path like C:\ffmpeg\bin\ffmpeg.exe) does not exist as far as n8n is concerned. You can fix it by building a custom n8n image with FFmpeg baked in and rebuilding it on every n8n release, or you can leave the container alone and send the video job to an API such as FFmpeg Micro through the HTTP Request node.

Run three commands inside the container, not on the host

Every wrong answer to this problem starts by checking FFmpeg on the wrong machine. Check it where the node actually runs. Get your container name from docker ps, then:

docker exec -it n8n which ffmpeg
docker exec -it n8n sh -c 'echo $PATH'
docker exec -it n8n ffmpeg -version

Empty output from the first command is your confirmation. The second tells you which directories the shell searches, which matters if you copied a binary into the image and dropped it somewhere like /opt/ffmpeg that is not on PATH. The third prints the build and, more usefully, the configuration flags, so you can see whether the FFmpeg you got was compiled with libx264, libmp3lame, and libfreetype or whether it's a stripped build that will fail later on a codec you need.

If docker exec -it n8n sh fails with something like exec: "sh": executable file not found, you're on a distroless image and there is no shell at all. That's an answer too, and it rules out about half the advice you'll find.

This is the exact shape of community.n8n.io thread 183559: a builder extracting audio from a Telegram video message hits /bin/sh: ffmpeg: not found, tries pointing the command at a Windows install path, and the accepted answer is that the node is executing inside Linux in a container where neither the binary nor that path exists.

Check whether Execute Command is even enabled

Before you spend an evening on a Dockerfile, confirm the node will run. n8n disabled the Execute Command node by default in v2.0 because arbitrary shell execution is a security risk on shared and multi-tenant instances. On n8n Cloud it has never been available, because you don't own the container. If your instance shows the node but refuses to execute it, no amount of FFmpeg installation will help.

The `apk add ffmpeg` recipe you'll find is now stale

Almost every tutorial and forum answer for this problem gives you the same four lines: switch to root, apk add --no-cache ffmpeg, switch back to the node user, done. That recipe was correct for years and it fails today. The official docker.n8n.io/n8nio/n8n image went distroless in 2026, which means there is no apk and no apt inside it to run. community.n8n.io thread 298633 (8 June 2026) is where this lands for most people, and the working answer is a multi-stage build that borrows Alpine's package manager first:

FROM alpine:3.20 AS pkg
RUN apk add --no-cache ffmpeg

FROM docker.n8n.io/n8nio/n8n:latest
USER root
COPY --from=pkg /usr/bin/ffmpeg /usr/bin/ffmpeg
COPY --from=pkg /usr/bin/ffprobe /usr/bin/ffprobe
COPY --from=pkg /usr/lib/ /usr/lib/
USER node

That copies a large pile of shared libraries into a base image that was deliberately slimmed down, and it can collide with libraries n8n itself ships. Some people instead copy /sbin/apk and libapk.so* into the distroless base and install from there. Either way, you now own an image. You are the person who rebuilds it when n8n ships a release, you are the person who finds out at 2am that the copy layer stopped working, and you are the person auditing FFmpeg CVEs. That is a real cost, not a theoretical one. It's also the reason the older threads on this topic (101937, 204259, 183559) read as authoritative and quietly no longer work.

A prebuilt community image is someone else's Dockerfile with the same problems

The n8n ecosystem answer to all of the above is a small pile of unofficial images: xzautomation/n8n-ffmpeg, marcospauloss/n8n-ffmpeg, abduosmanaj/n8n-ffmpeg and others. They work. Pull one and ffmpeg -version prints something.

What you're accepting is a container built by a stranger, usually running as root, on an n8n version that lags upstream by however long since they last pushed, with an FFmpeg build whose configure flags nobody documented. Before you put one in production, run these two:

docker run --rm xzautomation/n8n-ffmpeg ffmpeg -version
docker run --rm xzautomation/n8n-ffmpeg n8n --version

If the n8n version is six releases behind, you've traded a maintenance job you control for one you don't. Same for the community nodes that promise "no binary installations or custom Docker images" by running FFmpeg on a vendor's cloud: those aren't installing FFmpeg in your container at all, they're the third path with a node wrapper on it.

Leave the container alone and send the job over HTTP

The third option is to stop trying to get a media encoder into an orchestration container. Take the same job, express it as an HTTP request, and let the Execute Command node stay disabled.

Extracting audio from that Telegram video is one command locally:

ffmpeg -i input.mp4 -vn -acodec libmp3lame -q:a 2 audio.mp3

As an API call, it's the HTTP Request node with Method POST, an Authorization header holding your key, and a JSON body naming the source video URL and the output you want. FFmpeg Micro runs the FFmpeg toolkit as a hosted API, so the job returns a job ID that you either poll or take back on a webhook, and the finished file comes back as a URL rather than bytes inside your n8n instance. Exact endpoint and field names are in the docs, and the free tier is enough to test the workflow before you decide.

Fixing PATH usually moves the failure one node to the right

Getting ffmpeg -version to print is not the finish line, and two failures show up immediately after.

The first is filesystem scope. Your command writes /tmp/output.mp4, the next node tries to read it, and you get a missing file. In queue mode the workflow step that ran the command and the step that reads the file can be different worker containers with different /tmp. Even on a single container, /tmp is gone on restart. Write to a mounted volume shared by every n8n container, or don't write to disk at all and pass URLs between steps. The same principle is why Google Drive video automation fails in n8n when you route binaries through the workflow.

The second is memory. n8n holds binary data in memory by default, and pulling a 1GB video into a Read File node will take the whole instance down, not just the execution. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem moves it to disk and buys you headroom, but it doesn't change the architecture: FFmpeg itself needs RAM and CPU that your automation container was never sized for. There's a longer breakdown in how to fix n8n running out of memory on large video files.

Common pitfalls

Five mistakes produce a second round of confusion after the first fix:

When installing FFmpeg in the container is the right call

Baking FFmpeg into your own image is genuinely the better choice in a few cases. If your videos never leave your network for compliance reasons, an outbound API is off the table. If you're running hundreds of renders an hour on hardware you already pay for, per-job pricing loses to a beefy box you control. If you need a specific FFmpeg build, a patched filter, or hardware encoding through NVENC on a GPU host, a managed API won't expose that knob.

A self-hosted container that bundles media endpoints is the other honest option in that category, and it's free, but it comes with a queue, storage config, and timeout ceilings you'll be tuning yourself. That trade is worked through in the NCA Toolkit is free, self-hosting it isn't cheap.

FAQ

Why does FFmpeg work on my server but not in n8n?

FFmpeg installed on the host and FFmpeg inside the n8n container are two different things. The Execute Command node shells out inside the container's filesystem, which has its own PATH and its own set of binaries, so a host install is invisible to it. Verify with docker exec -it n8n which ffmpeg, not with which ffmpeg on the host.

Can I install FFmpeg on n8n Cloud?

You cannot install FFmpeg on n8n Cloud. There is no shell access to the managed container and the Execute Command node isn't available, so the only routes are a community node or an HTTP Request node pointed at a video API.

Does `apk add ffmpeg` still work in the n8n Docker image?

RUN apk add --no-cache ffmpeg no longer works against the current official n8n image, because that image is distroless and ships no package manager. The multi-stage workaround is to install FFmpeg in an Alpine stage and copy the binaries and libraries across, and it needs re-verifying on each n8n release.

Which n8n FFmpeg Docker image is safest?

The safest n8n FFmpeg image is one you build yourself from the official base, because you control the n8n version, the FFmpeg build flags, and the user it runs as. If you use a third-party image such as xzautomation/n8n-ffmpeg, check both n8n --version and ffmpeg -version inside it before trusting it in production.

How do I run FFmpeg in n8n without Docker changes?

Use the HTTP Request node to send the job to a hosted FFmpeg API and take back a URL. The n8n container stays untouched, the encoding CPU and memory sit somewhere else, and the workflow survives n8n upgrades. A worked example of chaining several of these calls is in clip, caption, and reformat video in one n8n workflow.

If you'd rather spend the next hour on the rest of the workflow than on a Dockerfile you'll be maintaining for the next year, wire up the HTTP Request node and run one job against the free tier: sign up free.