n8n 2.0 has been the stable release of the open source automation platform since December 2025. The 1.x branch only received security fixes for three months, until March 2026. Staying on it leaves your production without a safety net. The good news is that upgrading breaks a limited set of things, always the same ones, and the vendor ships a tool that finds them before you touch the server.
This article lists the exact breaking changes, the server prep work, a six-step migration and what n8n 3.0 brings. If you are new to the tool, start with our complete guide to n8n. If your question is about budget, our article on what n8n really costs breaks down per-execution billing.
What n8n 2.0 actually changes
n8n 2.0 is a hardening release. The vendor bundled three projects into the same major version. The first isolates code execution. The second makes storage more reliable. The third separates what you edit from what runs in production. In its launch announcement, n8n puts the new SQLite driver at up to ten times faster in its own benchmarks.
The context explains the scale of the work. Between version 1.0 and version 2.0, the project went from roughly 30,000 to more than 160,000 GitHub stars, and its forum from 6,267 to 115,192 members. A user base that size runs in production, with customer data and access to internal systems. The permissive defaults of the early days no longer held.
The six breaking changes that kill an n8n workflow
Not every n8n 2.0 change carries the same weight. Six of them flatly stop a workflow that ran fine the day before. The first three are critical, in the sense that the workflow fails on its very first run after the upgrade.
- The Start node is gone. It was the original way to begin a workflow. Replace it with a Manual Trigger for manual runs, or an Execute Workflow Trigger if another workflow calls this one. A disabled Start node can simply be deleted.
- The Code node no longer reads environment variables. N8N_BLOCK_ENV_ACCESS_IN_NODE now defaults to true. Any script that read process.env now errors out. Secrets belong in platform credentials.
- Task runners are on by default. Code runs in an isolated process, in secure mode. The most visible consequence hits the $evaluateExpression helper, which no longer works inside the Code node and returns null or an error.
- Sub-workflows return their output. In 1.x, a parent workflow waiting on a paused child received the child's input. It now receives its final result. That fix finally makes human-in-the-loop nodes usable inside a sub-workflow.
- Four nodes for retired services are removed. Spontit, crowd.dev, Kitemaker and Automizy leave the catalogue because the services behind them no longer exist.
- The Activate toggle becomes Publish. This one deserves its own section below, because it changes a way of working and not just a label.
Why your Code node no longer behaves the same
Task runners are the real heart of n8n 2.0. Previously, the JavaScript in a Code node ran in the same process as n8n itself. A badly written script, or a deliberately malicious one, could see server memory and environment variables. Since version 2.0, that code runs in a separate process with reduced rights.
Three side effects keep coming up in the official community. The first is the $evaluateExpression helper described above, for which the breaking changes documentation recommends moving the evaluation out of the Code node rather than re-enabling insecure mode. The second hits Python, whose old in-browser execution gives way to a real interpreter on the runner side. The third is the timeout, since a script that finds no free runner fails with an expiry message.
The Activate toggle is gone, meet Save and Publish
In n8n 1.x, one action was enough. You edit a workflow, you save, and the saved version goes to production if the workflow is active. An experiment left as-is would genuinely run. n8n 2.0 cuts that link. Edits autosave to a draft, typically within one to five seconds, and production keeps running the last published version.
That change answers a problem I described on LinkedIn in February 2026, in a post on where a coding agent stops and an automation platform starts. The trap I flagged fits in one sentence. When it works locally, nobody checks that it is genuinely in production. And when a workflow breaks at three in the morning, you do not want a terminal. You want readable logs, automatic retries and an alert.
In practice, publishing is asynchronous. n8n works out the difference between the last published version and the new one, then only reapplies the triggers that changed. Unchanged webhooks and schedules keep running without interruption. The button shows Publishing until the result is confirmed, and that state lives on the server, so reloading the page does not lose it.
What to prepare on the server side
This part only concerns self-hosted instances. It needs a maintenance window and a backup, because a database schema migration cannot be replayed backwards. Here are the settings that change their default or disappear.
| Setting | Before | In n8n 2.0 | What you need to do |
|---|---|---|---|
| Database | MySQL, MariaDB, PostgreSQL or SQLite | PostgreSQL or SQLite | Move your data to PostgreSQL before upgrading |
| N8N_DEFAULT_BINARY_DATA_MODE | default, in memory | filesystem, database or s3 | Pick a mode and check the container has disk space |
| N8N_RESTRICT_FILE_ACCESS_TO | Unset, the whole disk | The ~/.n8n-files folder | Move the files your workflows read or write |
| N8N_SKIP_AUTH_ON_OAUTH_CALLBACK | true | false | Retest every OAuth integration after the switch |
| Configuration file permissions | Unrestricted | 0600 required | Fix the permissions, or disable the check on Windows |
| n8n --tunnel | Available | Removed | Switch to ngrok, localtunnel or Cloudflare Tunnel |
Two more settings go unnoticed until the incident. The Git node now blocks bare repositories by default. And the N8N_CONFIG_FILES variable has been removed, so an instance that loaded its configuration that way starts on default values without saying so clearly.
How to migrate from n8n 1.x to 2.0 without breaking production
The order of operations matters more than speed. n8n ships a built-in migration report, available in the later releases of the 1 branch, under Settings then Migration Report. It is restricted to global admins of the instance. It shows how many of your workflows will pass unchanged, and sorts the remaining issues into critical, medium and low.
That last run date is the most useful detail in the report. In most of the instances Tandem takes over, a good half of the listed workflows have not run in months. Fixing them before the upgrade costs time for nothing. Sort by last run, handle what actually runs, archive the rest.
Your scripts and your agents migrate too
The most commonly forgotten point does not live in the interface. Everything that drives n8n from the outside was written for version 1.x. The update:workflow command line disappears and gives way to two separate commands, publish:workflow and unpublish:workflow. Deployment scripts that activated a workflow after an import therefore fail quietly unless someone reviews them.
The same goes for in-house integrations. The frontend hooks workflow.activeChange and workflow.activeChangeCurrent are replaced by workflow.published. Monitoring wired to the old hooks keeps running while never reporting an event, which is the worst kind of failure.
The most recent case is coding agents that write n8n for you. I filmed that setup in my tutorial on generating n8n workflows with Claude Code, and detailed it in an edition of my newsletter. It comes down to three pieces, an MCP server exposing the node catalogue, an API key to your instance, and a context file that explains the project to the agent.
That setup still works on n8n 2.0, with one condition. The agent relies on what it knows of the node catalogue, so a model trained on version 1.x will hand you a Start node or a script that reads process.env. Two lines in the context file fix it. State the major version of your instance, and explicitly forbid the removed nodes.
The same reasoning applies to your production agents. If you built agents with the AI Agent node, our tutorial on building an AI agent in n8n covers the expected structure and the guardrails to set before going live.
n8n 3.0 lands in October 2026, and Docker becomes mandatory
Migrating to n8n 2.0 expecting two quiet years would be a planning mistake. The official page of 3.0 breaking changes announces the next major version for October 2026. It carries a deployment change that will affect a lot of European instances.
- Self-hosting requires Docker. Installations launched with npm or npx will no longer be supported. n8n will not even publish a runnable package on npm anymore.
- The task runner timeout drops to one minute, down from five minutes today. A heavy script in a Code node will fail unless you set the value explicitly.
- Unverified community packages are off by default. Any node installed from npm without verification will need deliberate re-enabling.
- Version 1 of the AI Agent node is removed, along with its SQL Agent, Conversational Agent, ReAct and Plan and Execute modes. Workflows already on Tools Agent are unaffected.
- The binary data folder is renamed. A volume mounted on the old path stops n8n from starting if both folders exist.
Should you migrate to n8n 2.0 now
Yes, and the question barely stands any more. The 1.x branch stopped receiving security fixes in March 2026, and n8n 3.0 arrives in October 2026. An instance still on 1.x will have to chain two major upgrades, with the breaking changes of both stacked together. That is exactly the situation you want to avoid.
The migration itself is short when it is prepared. On the instances Tandem takes over, the technical part fits in half a day for a mid-sized instance, and most of the time goes into reviewing Code node workflows. The real risk was never the upgrade itself. It sits in the surrounding tooling, the deployment scripts and the monitoring nobody reviews.
If you are still weighing n8n against a closed platform, our comparison of n8n against Make and Zapier lays out the criteria. And if you would rather hand over the upgrade and the workflow review, Tandem runs these projects through its n8n agency offer and its Autopilot offer.
