n8n 3.0 disables community nodes: keep your FFmpeg step alive

Your FFmpeg community node worked yesterday, and the workflow using it is about to stop running. n8n 3.0.0 beta ships October 27, 2026, stable 3.x in early December, and one default change turns off every community package n8n hasn't verified. Not just new installs. The ones already in ~/.n8n/nodes stop loading too.

Quick answer: In n8n 3.0, community nodes that n8n has not verified stop loading, because N8N_UNVERIFIED_PACKAGES_ENABLED flips from true to false by default. A self-hoster can set it back to true to keep an unverified FFmpeg node alive, but that pins a security default n8n deliberately changed, and the switch doesn't exist on n8n Cloud. The durable fix is to delete the node and run the video step as one HTTP Request call to a hosted FFmpeg API such as FFmpeg Micro: submit a job, poll for status, download the output, with no node policy that can disable it.

The exact change, and the date it bites

n8n's v3.0 breaking changes doc is specific: the default for N8N_UNVERIFIED_PACKAGES_ENABLED goes from true to false, so you can no longer install unverified community nodes from npm, and already-installed unverified nodes stop loading. The announcement thread puts the beta on October 27, 2026 and stable 3.x in early December.

That flip isn't in n8n's headline three changes (Docker-only self-hosting, 35+ removed legacy nodes, and stricter defaults including a one-minute Code node task timeout), so the self-hoster running a third-party FFmpeg node gets the least warning.

The upgrade is one-way. Inventory while you're still on 2.x, where Settings > Migration Report buckets your workflows as upgrade blocked, executions will fail, or behavior changes.

Which video nodes stop loading

The FFmpeg slot in n8n is crowded with single-maintainer npm packages, and almost none are verified. n8n-nodes-mediafx processes on the n8n instance and pulls its binary through @ffmpeg-installer/ffmpeg. Then there's the long tail of forks under @raisaroj, @saitrogen, @qwqtoday, dioveath, shmeller86, revolabs-io and ArielleTolome, plus @ffhub/n8n-nodes-ffhub, which announced itself in the forum with submit/get/poll operations against a cloud renderer. Anything installed from the in-editor community panel is an unverified package, and the 3.0 default switches it off.

A few vendor-owned FFmpeg nodes have passed n8n's verification review and keep loading. If yours is one, this change misses you, but you're exposed next time the policy moves.

List what you actually have:

docker compose exec n8n ls /home/node/.n8n/nodes/node_modules
docker compose exec n8n cat /home/node/.n8n/nodes/package.json

A package that stops loading doesn't delete your workflow. The node type is never registered, so n8n can't resolve the step and the execution dies there, while the workflow JSON still looks fine.

Path 1: pin the env var, and know what you just signed up for

Setting N8N_UNVERIFIED_PACKAGES_ENABLED back to true gets a broken instance running again fast, and it's a stopgap, not a fix. In Docker Compose:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:3.0.0
    environment:
      - N8N_COMMUNITY_PACKAGES_ENABLED=true
      - N8N_UNVERIFIED_PACKAGES_ENABLED=true
      - N8N_RUNNERS_TASK_TIMEOUT=300

Three things come with that choice. N8N_UNVERIFIED_PACKAGES_ENABLED only applies while N8N_COMMUNITY_PACKAGES_ENABLED is true; per n8n's nodes env-var reference, setting the latter to false disables verified packages too. You also own a security default against the project's direction on every future upgrade, including ones that remove the flag. And unverified packages were never installable on n8n Cloud, so Cloud instances don't have this path.

Path 2: "wait for it to get verified" is not a plan

Check the integrations directory for your package, but if the node runs FFmpeg locally, read n8n's verification guidelines first. Verification requires an MIT license, no external dependencies, and no access to environment variables or the file system, with exactly one third-party service per package.

A node whose whole job is to resolve an FFmpeg path and shell out to a binary can't satisfy those: it needs an external dependency to find or ship the binary, it reads FFMPEG_PATH from the environment, and it writes temp files to disk. That category is structurally ineligible, so there is no wait to sit out.

Upstream is worse. A fix merged in the n8n-nodes-claudecode node on October 2, 2026 documented that n8n's community installer strips devDependencies, peerDependencies and optionalDependencies before running npm install --ignore-scripts=true, so a package can't ship a platform binary through n8n at all. Every community node promising local video processing is really promising a server-level FFmpeg install, and the official image went distroless this year, so apk add ffmpeg no longer works.

Path 3: replace the node with an HTTP Request chain

A plain HTTP Request node is a core node: no community package policy, no verification review, no install step, and it works the same on Cloud and self-hosted. The encoding runs on someone else's machine, outside the task-runner timeout you just lost.

Shape of the call against FFmpeg Micro's API: request a presigned upload URL, PUT the file to storage, confirm the upload, create the transcode job, then poll the job id until status is completed and fetch a signed download URL. There are no completion webhooks for callers, so the polling loop below is the pattern. Status checks, job listing and downloads aren't metered, so polling every five seconds costs nothing. More than 300 builders already run their video step from Make or n8n this way.

The submit, poll and download half is below, ready to paste onto a canvas. It assumes the previous node is the upload confirm, whose response carries result.fileUrl:

{
  "nodes": [
    {
      "parameters": {
        "method": "POST",
        "url": "https://api.ffmpeg-micro.com/v1/transcodes",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "Authorization", "value": "Bearer YOUR_API_KEY" }
          ]
        },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\"inputs\":[{\"url\":\"{{ $json.result.fileUrl }}\"}],\"outputFormat\":\"mp4\",\"preset\":{\"quality\":\"medium\",\"resolution\":\"1080p\"}}",
        "options": {}
      },
      "id": "submit-job",
      "name": "Submit transcode job",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [0, 0]
    },
    {
      "parameters": { "amount": 5 },
      "id": "wait-5s",
      "name": "Wait 5s",
      "type": "n8n-nodes-base.wait",
      "typeVersion": 1.1,
      "position": [220, 0],
      "webhookId": "poll-gate"
    },
    {
      "parameters": {
        "url": "=https://api.ffmpeg-micro.com/v1/transcodes/{{ $('Submit transcode job').item.json.id }}",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "Authorization", "value": "Bearer YOUR_API_KEY" }
          ]
        },
        "options": {}
      },
      "id": "poll-status",
      "name": "Check job status",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [440, 0]
    },
    {
      "parameters": {
        "conditions": {
          "options": { "caseSensitive": true, "typeValidation": "strict", "version": 2 },
          "conditions": [
            {
              "id": "done",
              "leftValue": "={{ $json.status }}",
              "rightValue": "completed",
              "operator": { "type": "string", "operation": "equals" }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "is-done",
      "name": "Completed?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [660, 0]
    },
    {
      "parameters": {
        "url": "=https://api.ffmpeg-micro.com/v1/transcodes/{{ $('Submit transcode job').item.json.id }}/download",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "Authorization", "value": "Bearer YOUR_API_KEY" }
          ]
        },
        "options": {}
      },
      "id": "get-url",
      "name": "Get download URL",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [880, -100]
    },
    {
      "parameters": {
        "url": "={{ $json.url }}",
        "options": {
          "response": {
            "response": { "responseFormat": "file", "outputPropertyName": "data" }
          }
        }
      },
      "id": "fetch-file",
      "name": "Download output",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [1100, -100]
    }
  ],
  "connections": {
    "Submit transcode job": { "main": [[{ "node": "Wait 5s", "type": "main", "index": 0 }]] },
    "Wait 5s": { "main": [[{ "node": "Check job status", "type": "main", "index": 0 }]] },
    "Check job status": { "main": [[{ "node": "Completed?", "type": "main", "index": 0 }]] },
    "Completed?": {
      "main": [
        [{ "node": "Get download URL", "type": "main", "index": 0 }],
        [{ "node": "Wait 5s", "type": "main", "index": 0 }]
      ]
    },
    "Get download URL": { "main": [[{ "node": "Download output", "type": "main", "index": 0 }]] }
  }
}

Move that Authorization header into a Header Auth credential before you ship. The false branch of Completed? loops back into the Wait node, which is how you poll without a Code node. Add a second condition on status equal to failed; failed jobs are never billed.

The DIY fallback breaks in the same release

Dropping the community node to hand-roll the step with Execute Command plus binary file nodes doesn't work either. Read Binary File, Read Binary Files and Write Binary File are gone from 3.0's 35+ removed nodes, replaced by Read/Write Files from Disk, and Item Lists is replaced by Split Out and Aggregate. N8N_RUNNERS_TASK_TIMEOUT drops from 300 seconds to 60, so a Code node doing real encoding dies after a minute unless you set the variable back. The Compression node's decompression cap falls from 2 GiB to 256 MiB, and $evaluateExpression() is gone.

A one-minute task budget and a 256 MiB archive cap are both smaller than an ordinary video job, so the download-process-upload pattern loses three parts at once. Our walkthrough of which 3.0 changes to fix in which order covers the rest, and the FFmpeg-step-specific list covers the Docker-only move.

Community node versus HTTP Request, on what matters

An unverified community node and an HTTP Request chain barely differ on features. They differ on who owns the step surviving the next upgrade.

| | Unverified community node | HTTP Request |
|:--|:--|:--|
| Survives the 3.0 flip | Only if you pin the env var | Yes, core node |
| Works on n8n Cloud | Never installable | Yes |
| Needs FFmpeg on the server | Yes | No |
| A future node policy can disable it | Yes | No |

Common pitfalls when you cut over

FAQ

Do unverified community nodes stop working, or just stop installing, in n8n 3.0?

Unverified community nodes do both in n8n 3.0: the breaking-changes doc says you can no longer install them from npm, and that already-installed ones stop loading after the upgrade.

Can an FFmpeg community node ever become verified?

A node that runs a local FFmpeg binary can't be verified by n8n. Verification requires an MIT license, no external dependencies, and no file system or environment access, and a local-FFmpeg node needs all three.

I'm on n8n Cloud and my video node is gone. Can I set the env var?

n8n Cloud users can't set N8N_UNVERIFIED_PACKAGES_ENABLED, and unverified packages were never installable on Cloud. If a node vanished there, it was a verified package that changed status, so the HTTP Request path is your option.

What's the real deadline, the October 27 beta or the December stable?

Treat early December as the deadline and the October 27 beta as your test window. Run the beta against a copy of your workflows now; the upgrade to 3.x can't be rolled back.

How much does moving the video step to an API cost?

FFmpeg Micro's free tier gives a new account 200 tokens with no card, about 33 minutes of video, and one token buys 10 seconds of input metered per second. Paid plans start at $19.99 a month for 2,500 tokens. Status checks, job listing and downloads are free, and billing follows the duration of the video you process, not the encode time.

The beta lands tomorrow, and the fastest way to know whether the HTTP path covers your job is to run it once. The quickstart creates a temporary API key and walks the presigned upload, transcode, poll and download with the request and response at each step. Sign up free and have a finished job before you touch your Compose file.