Affiliate disclosure: This post contains affiliate links. If you sign up for n8n Cloud through n8n or hosting through hostinger, Automated Wealth Lab may earn a commission at no extra cost to you. Prices below were checked against published sources in October 2026.
n8n 2.0 is not a version bump. It’s a rebuild of how code execution, configuration, and database support work — and the upgrade path that used to be “pull the new image and restart” will now leave your instance in pieces. This guide documents what breaks, the migration path for each break, and the decision math on whether to fix your self-hosted setup or move to Cloud.
- What breaks in 2.x upgrades
- 1. Task runners leave the main Docker image (the big one)
- 2. Python gets rebuilt (Pyodide is gone)
- 3. Nodes disabled or removed by default
- 4. Database and storage changes
- 5. Configuration and CLI changes
- The step-by-step migration path
- Step 1: Inventory (before upgrading)
- Step 2: Fix the foundation
- Step 3: Upgrade in a staging copy
- Step 4: Cut over
- Decision math: fix self-host vs move to Cloud
- FAQ
- Methodology
- Sources
Nothing here is a personal upgrade story. Every breaking change below comes from n8n’s own published 2.0 breaking-changes documentation and corroborating community write-ups.
What breaks in 2.x upgrades
1. Task runners leave the main Docker image (the big one)
In n8n 1.x, Code-node JavaScript and Python ran inside the main n8n process. In 2.0, code execution moves to separate Task Runner processes for isolation. Starting with v2.0, the main n8nio/n8n Docker image no longer includes the task runner for external mode — external-mode setups running off the main image break on upgrade; you now need the separate n8nio/runners image.
Related Code-node changes:
- Environment variables are blocked by default in the runner environment. Code that reads
process.envgets nothing unless you explicitly allow variables through. Use n8n credentials or other secure methods for secrets. $evaluateExpression()no longer works in the Code node under the new secure-mode default. Fix options: rewrite the logic in plain JavaScript, evaluate the expression in an Edit Fields node before the Code node, or setN8N_RUNNERS_INSECURE_MODE=trueas a temporary, production-discouraged workaround.
2. Python gets rebuilt (Pyodide is gone)
The old Pyodide-based Python Code node and tool are removed, replaced with a task-runner-based implementation using native Python. Starting in 2.0, Python Code nodes work only with task runners in external mode — and the native Python variant drops built-ins like _input and dot access notation. If your workflows use Python Code nodes, you must set up external-mode task runners and review every Python node for compatibility.
3. Nodes disabled or removed by default
ExecuteCommandandLocalFileTriggerare disabled by default. If workflows depend on them, updateNODES_EXCLUDE— e.g.,NODES_EXCLUDE="[]"enables all nodes, or remove only the specific nodes you need.- Removed nodes: Spontit, Crowd.dev, Kitemaker, Automizy (all four services retired), plus the Start node.
4. Database and storage changes
- MySQL and MariaDB are no longer supported. Migrate to PostgreSQL or SQLite before upgrading.
- SQLite non-pooling driver removed. Use the pooling driver.
- Binary data memory mode dropped. Use filesystem or S3 storage.
- Settings file permissions enforced: config files now require
0600(owner read/write only).
5. Configuration and CLI changes
- The
--tunnelCLI option is gone — use a reverse proxy or Cloudflare Tunnel instead. - The
N8N_CONFIG_FILESenvironment variable is removed. - Task runners are enabled by default in 2.0.
- CLI commands changed:
update:workflowbecomespublish:workflow/unpublish:workflow. Audit deployment scripts before upgrading.
Your best first move: n8n 2.0 ships a Migration Report at Settings → Migration Report. Run it before you plan anything.
The step-by-step migration path
Step 1: Inventory (before upgrading)
- Open Settings → Migration Report on your current instance and save the findings.
- List every Code node: language, and whether it uses
$evaluateExpression(),_input, dot-access notation, or environment variables. - Check your database: MySQL/MariaDB means a database migration comes first.
- Check for disabled-by-default nodes and grep deployment scripts for
update:workflow,--tunnel, andN8N_CONFIG_FILES.
Step 2: Fix the foundation
- Database first. If on MySQL/MariaDB, migrate to PostgreSQL (or SQLite for small instances) while still on 1.x.
- Back up everything. Full database dump plus exported workflow JSONs, stored off the server.
- Update docker-compose.yml. Add the
n8nio/runnersservice for external-mode task runners alongsiden8nio/n8n. - Set file permissions. Ensure config files use
0600.
Step 3: Upgrade in a staging copy
- Stand up a copy of your instance and upgrade that to 2.x.
- Run the Migration Report on the upgraded copy and work through every flagged item.
- Test-execute every production workflow end to end on the staging copy.
Step 4: Cut over
Schedule a maintenance window, upgrade production, run the Migration Report one final time, and spot-check critical workflows. Keep the 1.x backup for at least two weeks.
Decision math: fix self-host vs move to Cloud
| Option | Monthly cost | What you get | The catch |
|---|---|---|---|
| Self-hosted Community Edition | ~$5–10/mo for the server | Free software, unlimited executions; you own the data | You do the 2.0 migration yourself; you own uptime and backups |
| n8n Cloud Starter | €20/mo annual (€24 monthly) | 2,500 executions/mo, migration handled by n8n | Execution-capped; overages need a bigger tier |
| n8n Cloud Pro | €50/mo annual (€60 monthly) | 10,000 executions/mo, admin roles, workflow history | Same caps, higher ceiling |
| n8n Business (self-hosted license) | ~€667/mo annual | 40,000 executions, SSO, Git, environments | Only for teams needing governance |
The honest decision rule:
- Stay self-hosted if: your monthly executions are high, you’re comfortable with Docker, and data residency matters. At ~$6/mo for a VPS vs €20/mo for Starter, self-hosting saves roughly $170/year at the low end.
- Move to Cloud if: the Migration Report shows a big remediation list, you’d rather pay than learn Docker networking, or uptime SLAs matter to your clients.
FAQ
Q: Will upgrading to n8n 2.0 break my existing workflows?
A: Possibly: Code nodes using $evaluateExpression(), Python nodes relying on Pyodide behavior, workflows using ExecuteCommand/LocalFileTrigger, and Docker setups running external-mode task runners off the main image. Run Settings → Migration Report before upgrading.
Q: Do I have to use the n8nio/runners image?
A: Only if you run task runners in external mode with Docker. The main image no longer includes the external-mode task runner as of 2.0.
Q: My Code nodes read environment variables. What do I do?
A: Env vars are blocked by default in 2.0. Use n8n credentials for sensitive data; explicitly allow specific non-sensitive variables through to the runner.
Q: Can I stay on n8n 1.x forever?
A: You can pin the image tag, but it’s a decaying position: no security fixes, no new nodes, growing incompatibility with 2.x-era templates.
Q: Is n8n Cloud cheaper than self-hosting after 2.0?
A: For low-volume users, arguably yes once you price your time. For high-volume needs, self-hosting at ~$5–10/mo still wins on raw cost.
Methodology
This is a documented migration guide compiled from published sources, not a hands-on upgrade log. Every breaking change comes from n8n’s published 2.0 breaking-changes documentation, cross-checked against two independent community write-ups (DEV and Medium, 2026). What was NOT done: no n8n instance was upgraded, no Docker containers were run, no workflows migrated or test-executed. Pricing from third-party breakdowns of n8n’s published pricing, checked 2026.
AWL verdict: n8n 2.0 is the most disruptive n8n upgrade a self-hoster has faced. Don’t “pull and pray” — run the Migration Report, stage the upgrade on a copy, fix flagged items in order. Then do the honest math: long remediation list + volume under 10,000 executions → n8n Cloud at €20–50/mo is rational; running hot + comfortable with Docker → a ~$6/mo VPS plus a weekend of migration keeps you on free Community Edition.
Sources
- https://github.com/gthin78/n8n-docs/blob/HEAD/docs/changelog/v20-breaking-changes.md
- https://dev.to/ciphernutz/n8n-20-what-changed-and-should-you-upgrade-dpe
- https://medium.com/@databytoufik/n8n-2-0-what-changed-68faedd3bb0a
- https://www.cloudzero.com/blog/n8n-pricing/
- https://gizmodo.com/best-web-hosting/self-host-n8n
- https://github.com/lxcardoza993/awesome-oss-sponsorship/blob/HEAD/docs/affiliate-programs.md
- https://www.wpressblog.com/best-web-hosting-affiliate-programs/
