n8n 2.0 enables task runners by default and blocks Code node env access

n8n 2.0 is a defaults-changing release rather than a feature drop, and that distinction matters for anyone running the workflow automation platform in production. A walkthrough published on dev.to argues that the real upgrade question is not whether existing workflows still open, but whether they still run with the same inputs, permissions, side effects and outputs.

Task runners are now on by default

The headline change is that task runners ship enabled, and Code node executions go through them. The isolation this provides is a security improvement, but it also means code that ran under 1.x can behave differently after upgrading. The dev.to author recommends setting N8N_RUNNERS_ENABLED=true on a current 1.x installation first, so compatibility problems surface before the version jump.

Code nodes lose environment variable access

N8N_BLOCK_ENV_ACCESS_IN_NODE now defaults to true, so a Code node that reads process.env.MY_API_KEY will fail unless the setting is relaxed. The suggested fix is structural: stop using Code nodes as a place to hold secrets and route them through n8n credentials instead — for example, feeding an HTTP Request node from a credential rather than passing along a key pulled from the environment. The article notes this pattern is also easier to maintain.

$evaluateExpression breaks inside Code nodes

Under the secure task-runner model, $evaluateExpression() no longer works inside the Code node as it did before, and n8n documents this as a breaking change. The recommended alternatives are to evaluate the expression in an earlier node such as Edit Fields and pass the result into the Code node, or to rewrite the logic as plain JavaScript. n8n also documents an insecure-mode workaround, but the article frames it as a temporary compatibility option rather than a production answer.

Python execution leaves Pyodide behind

The Pyodide-based Python implementation is removed, and Python Code nodes now run under the task-runner model, requiring task runners in external mode. The new environment does not support the same built-in variables the Pyodide version offered, and code relying on _input needs review. Because the node is still called Python, it is tempting to assume nothing changed; the article warns against that and suggests auditing every workflow containing Python code, Code nodes and AI agents with Python tools, then testing each one.

Command and file trigger nodes are disabled

ExecuteCommand and LocalFileTrigger, which can run commands or interact with the filesystem, are turned off by default. A workflow that chains a webhook into ExecuteCommand will not simply keep working after the upgrade. The article advises reviewing which of these nodes are genuinely required and treating re-enabling them, through node-availability configuration such as NODES_EXCLUDE, as a deliberate infrastructure decision rather than something carried over from an old setup.

Local file access is scoped

File operations are now restricted by default, with ~/.n8n-files as the allowed location for the relevant operations. Self-hosted installations that process PDFs, images, CSVs, documents, generated reports or uploaded files should identify every workflow using filesystem nodes and check their paths before upgrading.

The database story changes twice

MySQL and MariaDB are no longer supported as the database n8n uses for its own storage, with PostgreSQL recommended for long-term compatibility. The article draws a useful distinction: the MySQL node for connecting to application databases still works, and the change concerns only n8n's internal database. Anyone running n8n itself on MySQL or MariaDB needs to migrate before upgrading.

SQLite gets a driver swap as well: the legacy driver is replaced by a pooled driver using WAL mode, one write connection and a pool of read connections. According to the article, n8n's benchmarks put the pooled setup at up to 10x faster than before, though actual performance depends on the workload. Setting DB_SQLITE_POOL_SIZE=2 lets you try the pooled behavior ahead of the upgrade.

The dev.to piece also flags changes around OAuth, binary data and workflow publishing, though its detailed guidance covers the areas above.

Why it matters

n8n 2.0 shifts the platform from permissive defaults to secure-by-default ones: isolated code execution, blocked environment access, disabled command nodes and scoped file access. That is the right long-term posture, but the cost lands on upgrade day, because workflows nobody edited can break when their assumptions about permissions and execution stop holding. The migration checklist follows directly from the changes: test task runners on 1.x, search Code nodes for process.env and $evaluateExpression, audit Python usage, enumerate command and filesystem nodes, and confirm which database n8n itself runs on. Teams that do that homework get the security improvements; teams that treat 2.0 as a routine version bump are the ones likely to meet the breaking changes mid-run.