n8n 3.0 beta is out: what we found upgrading to 3.0.1

The n8n 3.0 beta is out. n8n tagged 3.0.0 on October 27, 2026 and 3.0.1 on October 28, both as pre-releases, and published them only as Docker images (n8nio/n8n:3.0.1 with a matching n8nio/runners:3.0.1). There is no 3.x package on npm, and the beta and latest Docker tags still point at 2.x, so you have to pin 3.0.1 to try it.

We upgraded a test instance from 2.45.5 to 3.0.1 on October 28. It migrated in seconds, JavaScript and Python Code nodes kept working, a workflow with the removed Cron node stopped running, and Code tasks longer than a minute failed until we raised the timeout on both the n8n and the task runner container.

The short version

• Versions: 3.0.0 (October 27) and 3.0.1 (October 28), both "Pre-release" in n8n's release commits. The images label themselves N8N_RELEASE_TYPE=rc. Stable stays on 2.45.5 until 3.x stable, which n8n has announced for early December.
• Docker only. npm view n8n dist-tags shows latest 2.45.5 and next 2.46.1. That matches n8n's breaking changes page: 3.0 "doesn't publish a runnable n8n package to npm."
• What worked: the upgrade itself, webhooks, JavaScript and Python Code nodes on an external runner.
• What broke: a workflow using the removed Cron node, and a 75-second Code node task (until we set N8N_RUNNERS_TASK_TIMEOUT on both containers).
• Going back: 2.45.5 started on a copy of our upgraded test data and ran its workflows. n8n says there is no going back to 2.x, so treat that as luck on a tiny SQLite instance, not a rollback plan.

How to try the 3.0 beta

Pin the exact version on both images, on a copy of your instance, never production:

services:
  n8n:
    image: n8nio/n8n:3.0.1
  task-runners:
    image: n8nio/runners:3.0.1

Don't rely on tags. On October 28, Docker Hub shows beta and next on 2.46.1, latest and stable on 2.45.5, and no floating 3 or 3.0 tag. The v3-nightly images are still built daily, but they're builds of the 3.x branch, not the beta.

Before you upgrade the copy, update it to the latest 2.x, work through Settings > Migration Report, and take a full backup. Our one-way upgrade guide has the backup and restore steps, and the n8n 3.0 guide lists every breaking change.

What we tested

The test instance ran n8n 2.45.5, the current stable release, in Docker with the default SQLite database and an external task runner (n8nio/runners:2.45.5, N8N_RUNNERS_MODE=external). It had four published workflows, each started by a webhook or a trigger:

• a JavaScript Code node;
• a Python Code node (native Python);
• a JavaScript Code node that waits 75 seconds before returning;
• a workflow started by the legacy Cron node, which n8n 3.0 removes.

We checked each workflow on 2.45.5, stopped the instance, backed up the data volume, swapped both images to 3.0.1, and started it again. This is a small test, not a production-sized database: a Postgres instance with years of execution data will take longer to migrate and may hit problems we didn't.

Results on n8n 3.0.1

Removed nodes stop the workflow

On startup, 3.0.1 logged Published version holds node types this instance cannot load followed by Workflow cannot run on this instance: "Cron": Unrecognized node type: n8n-nodes-base.cron. The workflow didn't run. Replace removed nodes before the upgrade: Cron becomes the Schedule Trigger, and the full list is in the breaking changes page. On 2.x, the migration report at Settings > Migration Report lists the workflows that n8n 3.0 changes, so you can fix them first.

The 60-second Code node timeout

This one surprised us on the 2.x side. n8n 3.0 lowers the default N8N_RUNNERS_TASK_TIMEOUT from 300 to 60 seconds, per the breaking changes page. But with an external task runner, our 75-second task already failed at 60 seconds on 2.45.5, with Task execution timed out after 60 seconds.

The reason is in the runner container. Its launcher passes N8N_RUNNERS_TASK_TIMEOUT=60 to the runner process unless you set the variable yourself; we read it from the running process, and the launcher's config source has default=60. So with external runners, 60 seconds was already the effective limit on 2.x.

What fixed it:

• On 2.45.5: N8N_RUNNERS_TASK_TIMEOUT=120 on the runners container alone was enough. The task returned after 75 seconds.
• On 3.0.1: the same setting on the runners container alone wasn't enough, because n8n's own default is now 60. Setting N8N_RUNNERS_TASK_TIMEOUT=120 on both the n8n and the runners container made the task succeed.

services:
  n8n:
    environment:
      - N8N_RUNNERS_TASK_TIMEOUT=120
  task-runners:
    environment:
      - N8N_RUNNERS_TASK_TIMEOUT=120

Our task runners guide explains the two containers and their settings. When we tested the 3.0 nightly on October 18, it needed the same two-container fix.

Going back to 2.45.5

On a copy of the upgraded data, n8n 2.45.5 started (Recorded version change: 3.0.1 -> 2.45.5) and ran the JavaScript and Python workflows. Don't read that as a working rollback. n8n's 3.0 announcement says the upgrade is one way, with no going back to 2.x, our test database had almost nothing in it, and later 3.x versions may change data in ways 2.x can't read. Your rollback is the backup you take before upgrading, restored into the same 2.x version.

What's new in 3.0.0 and 3.0.1

Most of 3.0 is the breaking changes n8n documented in advance. The 3.0.0 changelog (compared with 2.45.0) also lists these changes worth knowing:

• Chat hub off by default, and granular credential sharing always on.
• Migration Report: export as CSV, a new "Executions might fail" impact, filtering by project, and workflow editors can triage findings for their own workflows.
• Deprecated nodes: the editor now prevents using them, and Edit Image versions 1 and 1.1 are removed, with a new version 2.
• Webhook and MCP Trigger nodes can authenticate through trusted sources.
• Community nodes: N8N_NODES_API_VERSION moves to 3, with a compatibility fix for community packages that declare supportedNodesApiVersion.
• Two reverted removals: the Execute Sub-workflow node keeps its "Run once for each item" mode, and the "Any workflow" caller policy stays. We covered these reverts before the beta.

3.0.1 is a bug-fix release: expression fixes in core (an ExpressionError name kept in minified builds, undefined values kept in QuickJS expression results), faster first load of the editor, and several editor UI fixes, including Safari opening its own context menu on the canvas.

We'll cover each 3.x beta that changes something you need to act on, and the stable release in December. For all release coverage, see the releases tag.