n8n 2.0: What Changed and Should You Upgrade?

If you run n8n in production, upgrading from 1.x to 2.0 is bigger than a version bump. The n8n 2.0 changes several defaults around Code nodes, task runners, Python execution, file access, databases, OAuth, binary data, and workflow publishing. Some of these changes are also security improvements while the others can actually change how an existing workflow behaves. But, instead of listing every new feature in n8n 2.0, this article focuses on the real questions that matter when you are running real workflows: What actually changed? Which workflows are most likely to break? What should you check before upgrading? How do you test the migration? When does upgrading make sense?

The First Thing to Understand: 2.0 Changes Defaults

The biggest theme in n8n 2.0 is being secure natively. Task runners are enabled by default, Code node access to environment variables is blocked by default, and nodes capable of arbitrary command execution are disabled by default. That means a workflow that performed on previous versions of n8n like 1.x can behave differently after the upgrade even if you never changed the workflow itself. For developers, this is more important than the UI changes. The migration question is not: "Does my workflow open, function?" It is: "Does my workflow still execute with the same inputs, permissions, side effects, and outputs?"

1. Task Runners Are Now the Default

This is one of the most important changes if your workflows use Code nodes. In n8n 2.0, task runners are enabled by default and Code node executions run on task runners. The result is having stronger isolation and security. Before upgrading, test your Code nodes with:
N8N_RUNNERS_ENABLED = true
This lets you find compatibility problems before making the 2.0 upgrade.

Why this matters
Imagine you have:

const secret = process . env . MY_API_KEY ; return [{ json : { key : secret } }];

In n8n 2.0, environment-variable access from the Code node is blocked by default. The relevant setting is:
N8N_BLOCK_ENV_ACCESS_IN_NODE = true
If your workflow depends on environment variables inside the Code nodes, it can stop working after the upgrade.

Better approach
Don't use the Code node as a secret store. Use n8n credentials for secrets whenever possible. For example:
Bad pattern: Code Node ↓ process.env.API_KEY ↓ HTTP Request
Prefer: Credential ↓ HTTP Request
Applying this change also makes the workflow easier to maintain.

2. $evaluateExpression() in Code Nodes Can Break

This is a particularly easy migration issue to miss. n8n 2.0's secure task-runner model means:
$evaluateExpression() no longer works inside the Code node as it did before.
n8n documents this as a breaking change. For example, if you have:
`const