The n8n 2.0 Upgrade in 2026: What Breaks and What to Fix

If you are still running n8n 1.x in production, the n8n 2.0 upgrade has stopped being optional maintenance. n8n published 2.0.0 in its changelog on 5 December 2025, and the company's own announcement said the 1.x line would receive security and bug fixes only for three months after that, through mid-March 2026. That support window closed months ago. The stable line has moved a long way since: n8n 2.34 shipped on 4 August 2026, with 2.34.5 listed as the current stable release and 2.35.2 in beta.

The reassuring part is that 2.0 was deliberately boring. n8n framed it as a release that strengthens the platform for enterprise-grade, mission-critical workflows rather than a feature launch. The dangerous part is that hardening means changed defaults, and changed defaults are what break a working instance quietly.

Here is what actually changes, which parts break production workflows, and the order to do the work in.

Run the Migration Report before you read anything else

n8n ships a Migration Report tool inside the product, under Settings and then Migration Report. It is available to global admins only. It scans your instance and separates findings into a Workflow Issues tab and an Instance Issues tab, so you can tell the difference between "fix this workflow" and "fix this deployment".

Each issue carries a severity. n8n defines Critical as fix before upgrading or workflows will fail, Medium as may cause unexpected behaviour or require attention soon, and Low as minor changes or deprecations that will not break functionality. For each affected workflow the report shows the publication state, the affected nodes, execution counts, and the last execution date.

That last column is the one most teams ignore and the one that matters most. A workflow with a Critical finding and no execution in eight months is a delete candidate, not a migration task. Sorting by execution count before touching anything typically halves the real work.

The n8n 2.0 upgrade changes that break working workflows

Task runners are on by default

In 2.0, `N8N_RUNNERS_ENABLED` defaults to true, and every Code node execution runs on a task runner. Task runners come in two modes. In internal mode, n8n launches the runner as a child process sharing the same user and group as n8n itself. In external mode, a launcher application runs the task runners, normally as a sidecar container using the runners image that bundles the launcher plus the JavaScript and Python runners.

n8n's documentation is unusually direct about which to pick: task runners are the only isolation layer between user-provided code and n8n, and without them, or with internal mode, anyone who can edit a workflow could potentially read your database, encryption key, stored credentials, and environment variables. External mode is the production answer. Internal mode belongs on isolated instances holding nothing sensitive.

Two deployment details catch people out. The task runner was removed from the main n8n Docker image, so external mode needs the separate runners image. And in queue mode, each worker needs its own sidecar container.

Code nodes lost environment variables and one convenience method

`N8N_BLOCK_ENV_ACCESS_IN_NODE` now defaults to true, so Code nodes can no longer read environment variables. If a workflow was pulling an API key or a base path out of the environment inside a Code node, it stops working on upgrade. You can set the variable back to false, but the better fix is to move those values into credentials, where they belonged in the first place.

Separately, the `$evaluateExpression()` helper no longer works inside the Code node, because secure mode does not evaluate strings as code. Calls return null or error. n8n lists three workarounds in order of preference: write the logic directly in JavaScript, evaluate the expression in an Edit Fields node before the Code node and read the result, or set `N8N_RUNNERS_INSECURE_MODE` to true. The third is explicitly discouraged for production, and n8n warns the method may be removed from the Code node entirely in a future version.

The Python Code node changed more than the JavaScript one. The Pyodide-based implementation was replaced by a task-runner-based native Python implementation, which means Python Code nodes only work with task runners in external mode. Built-in conveniences such as `_input` and dot access notation are gone, and the native Python tool now takes `_query` for the input string passed by an AI Agent.

The Start node is gone and Activate became Publish

The Start node is no longer supported. Manual executions use the Manual Trigger node, sub-workflows use the Execute Workflow Trigger node, and disabled Start nodes should simply be deleted.

The bigger conceptual change is deployment. The old Activate and Deactivate toggle has been replaced by Publish and Unpublish. Save now preserves your edits without changing production, and Publish pushes them live. n8n's stated reason is better control over when workflow changes go live, reducing the risk of accidentally deploying work-in-progress changes to production. In 1.x, saving an activated workflow updated production instantly.

If you script deployments, the `update:workflow` CLI command has been replaced by `publish:workflow` and `unpublish:workflow`, and the `--all` parameter was removed to prevent accidental bulk publishing. Frontend hooks moved too: `workflow.activeChange` and `workflow.activeChangeCurrent` are deprecated in favour of a `workflow.published` hook.

One more behavioural change is easy to miss. When a parent workflow calls a sub-workflow that enters a waiting state, the parent now receives the actual output from the end of the child workflow rather than the child's input. Anything built around the old behaviour needs review.

Your database and storage assumptions may not survive

MySQL and MariaDB are no longer supported as storage backends, having been deprecated back in 1.0. PostgreSQL is the recommended destination. The MySQL node continues to exist as a connector, which is a different thing entirely.

The legacy SQLite driver was removed, and the pooling driver is now the default and only SQLite driver, with WAL mode, a single write connection and a pool of read connections. n8n cites benchmarks showing it up to ten times faster, and the default pool size is 2.

In-memory binary data mode is gone. The remaining options are filesystem, database and s3, with filesystem the default in regular mode and database the default in queue mode. If your workflows move files, check disk provisioning before upgrading, not after.

Nodes for four retired third-party services were also removed outright. If a workflow references one of them, it will surface in the report.

The quiet configuration changes

These do not break workflows so much as deployments.

Settings files must now use 0600 permissions, controlled by `N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS`, which you can switch on before upgrading to test. OAuth callback URLs now require authentication by default. File operations are restricted to a default directory unless `N8N_RESTRICT_FILE_ACCESS_TO` says otherwise. Bare repositories in the Git node are disabled by default. The ExecuteCommand and LocalFileTrigger nodes are disabled by default because they allow arbitrary command execution and file system access, and re-enabling them through `NODES_EXCLUDE` is a decision you should make consciously rather than by reflex.

`N8N_CONFIG_FILES` was removed. `QUEUE_WORKER_MAX_STALLED_COUNT` was removed too, and with it the automatic retrying of stalled jobs, because n8n found the mechanism confusing and unreliable. If you depended on it, that retry logic is now yours to build. The `--tunnel` option is gone, so local webhook testing needs a real tunnelling tool. The dotenv library was upgraded, which changes how env files parse comments, multiline values and backticks. And the release channels were renamed from latest and next to stable and beta, with n8n recommending you pin to a specific version number rather than to a channel.

What you get for doing the work

The 2.x line has been productive. Human-in-the-loop approval for AI tool calls arrived in 2.6.0 in January 2026, letting you require explicit approval before an agent executes a sensitive tool. Version history gained a visual diff. OpenTelemetry support for workflow executions landed in 2.15.0. Connecting to MCP servers was simplified in 2.22.0 in May 2026. And 2.34, released on 4 August 2026, lets workers return webhook responses of any size by offloading large payloads to binary data storage instead of holding them in Redis.

For a sense of the pace behind those releases, n8n reported that since 1.0 in July 2023 its GitHub stars grew from around 30,000 to over 160,000, its community forum from 6,267 members to 115,192, and its team from 30 people to over 190, across more than 120 weekly releases.

A migration sequence that works

Run it in this order.

1. Run the Migration Report and export the findings before making any decisions. 2. Delete or archive dead workflows rather than fixing them. Execution count is your filter. 3. Stand up a staging instance on the same version as production and restore a copy of the database. Most 2.0 surprises are instance-level, not workflow-level. 4. Flip the new defaults on your 1.x staging instance one at a time. Task runners, blocked environment access, OAuth callback authentication and settings file permissions can all be tested before you change versions. This is the highest-value step in the whole process. 5. Migrate the database backend if you are on MySQL or MariaDB, and treat that as its own project with its own rollback plan. 6. Upgrade staging, re-run the report, and only then schedule production.

Back up your encryption key before any of this. Without it, restored credentials are unreadable, and no amount of careful upgrade planning survives that mistake.

At AbhijeetBuilts we typically run this as a two-week exercise on a client instance: one week of assessment and staging replication, one week of controlled cutover, using the new Publish model as an opportunity to introduce a proper review step rather than as an inconvenience to work around. Teams that treat the upgrade as a chance to tighten deployment discipline get considerably more out of it than teams chasing green checkmarks.

If you are running business-critical automation on n8n 1.x and are not certain what will break, get in touch through the website and we can scope the migration properly, starting with a read of your own Migration Report.