n8n v3 preview: what happened when we upgraded to the 3.0 nightly

n8n 3.0 has not been released: on October 18, 2026, the stable version is 2.43.7, the beta is 2.44.3, and there is no 3.x package on npm or 3.x tag on GitHub. But n8n publishes daily v3-nightly Docker images and weekly v3-rc images built from its 3.0 branch, so you can try the upgrade today. We upgraded a 2.x instance with Postgres and an external task runner to the October 18 nightly to see what breaks.

The results: modern workflows kept running, a workflow with the removed Function node failed with "Unrecognized node type", Code node tasks over a minute timed out, and rolling back to 2.43.7 worked on this build. One finding isn't in n8n's docs: with an external task runner, the new 60-second timeout has to be raised on both containers.

The short version

• No release date yet. n8n's breaking changes page says 3.0 "is releasing soon." n8n's internal v3 development guide targets "~October 2026."
• Preview images exist. n8nio/n8n:v3-nightly is rebuilt daily from the 3.x branch, and every Monday a build is also tagged v3-rc. They report their version as 2.x, not 3.0.
• Removed nodes fail at run time. A published workflow with a Function node still received its webhook, but the run failed.
• Raise the Code node timeout on both containers. With an external runner, setting N8N_RUNNERS_TASK_TIMEOUT on n8n alone, or on the runner alone, didn't help.
• The Migration Report found both problem workflows before the upgrade.
• Rollback worked on this nightly, but n8n's v3 plan allows destructive migrations after the release, so back up before you try the real 3.0.

For the full list of what 3.0 changes and a preparation checklist, see our n8n 3.0 breaking changes guide.

What the n8n v3 preview builds are

n8n develops 3.0 on a long-lived 3.x branch. Per its v3 development guide, 3.x is "whatever is on master, plus the breaking-change commits," and a job replays master into it every day at 06:00 UTC. A second job builds Docker images from it at 08:00 UTC, according to the nightly build workflow.

Don't be confused by the version number. n8n --version printed 2.44.0 in the October 18 nightly and 2.43.0 in the October 12 RC, and the nightly logged "Recorded version change: 2.43.7 -> 2.44.0" in the instance history. The images carry master's version until the real release.

How we tested

We used a Docker Compose stack like the one in our self-hosting guide: Postgres 18, n8n and an external n8nio/runners container, without the reverse proxy. We created four workflows on 2.43.2, upgraded to 2.43.7, took a backup, and then switched both images to v3-nightly-20261018:

• Legacy Function node: Webhook into a Function node, published.
• Modern Code nodes: Webhook into a JavaScript Code node and a Python Code node, published.
• Slow Code task: Webhook into a Code node that waits 75 seconds, published.
• Old AI Agent: a version 1 AI Agent node set to Conversational Agent, not published.

Results

Removed nodes break at run time, not at startup

The nightly started without complaint, and the Function workflow stayed published: its webhook still answered. The failure came when it ran, with this response:

{"code":0,"message":"Unrecognized node type: n8n-nodes-base.function"}

That's the behavior to plan for. Nothing at startup tells you a workflow is broken, so find these workflows before you upgrade. The Function node is one of more than 35 nodes 3.0 removes; the breaking changes page lists each one and its replacement.

The 60-second Code node timeout, and the setting that fixes it

n8n 3.0 lowers the default N8N_RUNNERS_TASK_TIMEOUT from 300 to 60 seconds. Our 75-second task failed at the 60-second mark:

Task execution timed out after 60 seconds

n8n's task runner docs list N8N_RUNNERS_TASK_TIMEOUT as an n8n instance variable. With an external runner, that wasn't enough. We tried three combinations:

The runner image passes this variable through to the runners (it's in the allowed-env list of the image's /etc/n8n-task-runners.json), so both sides enforce their own limit. If you run the runner as a sidecar, set it on both:

services:
  n8n:
    environment:
      N8N_RUNNERS_TASK_TIMEOUT: 300
  n8n-runner:
    environment:
      N8N_RUNNERS_TASK_TIMEOUT: 300

Better still, make long Code tasks shorter, for example by processing data in batches.

What to do on 2.x before the upgrade

Newer 2.x versions already block adding deprecated nodes

Since 2.43.3, released October 9, n8n refuses to save a workflow that adds a deprecated node, through the editor's API and through n8n import:workflow alike. It's a backport of "Block create/update of workflows with deprecated nodes" (#40706). On 2.43.7, both attempts failed with:

Cannot use a "n8n-nodes-base.function" node ("Function"): this node type is deprecated.
Replace the node with a supported alternative or remove it from the workflow.

Existing workflows aren't affected: the Function workflow we created on 2.43.2 kept running on 2.43.7, and we could still rename and save it. The block stops new uses, not old ones, so you still need to find and replace them.

Run the 3.0 Migration Report

On 2.43.7, the Migration Report for the 3.0 target found both problem workflows, Function node removed and Deprecated AI Agent modes removed, each marked as making executions fail. Neither was marked as automatically migratable, so they need manual fixes. It also listed four instance-level notices: the lower Compression node limits, the shorter task runner timeout, unverified community packages turning off, and the removal of workflow import from URL.

Open it in Settings > Migration Report (global admins only), fix Critical issues first, and re-scan. Our 3.0 guide explains each rule.

Can you roll back from n8n 3.0?

On this nightly, yes. After the upgrade, we pointed the same data at 2.43.7 again. It started, logged "Recorded version change: 2.44.0 -> 2.43.7", and the Function workflow ran again. We also restored the backup taken before the upgrade, using the steps in our update guide, and that worked too.

Don't count on the first path for the final release. n8n's v3 development guide says migrations on master must be non-destructive, and that "after the release of v3, you can create the destructive part of migration if needed." A future 3.x version may change the database in ways 2.x can't read. A backup of the database and the .n8n volume is the rollback that always works.

How to try the 3.0 preview safely

1. Use a copy, never production. Restore a backup into a separate Compose project with its own volumes and database, and unpublish workflows on the copy so triggers don't fire twice. Our update guide has the commands.
2. Pin a dated tag, such as n8nio/n8n:v3-rc-20261012.1 or v3-nightly-20261018, and give n8nio/runners the same tag.
3. Run your important workflows by hand and watch for "Unrecognized node type" errors and Code node timeouts.
4. Throw the copy away when you are done. Nightly builds change daily and aren't supported.

What's next

We will cover n8n 3.0 on release day in our news section, and update our 3.0 breaking changes guide as the changes settle. Until then, keep production on a pinned 2.x version: 2.43.7 is the current stable release.