The Code node was running a client’s data processing logic, and I had not thought about what that meant for the host machine. Someone in the Discord asked about sandboxing, and I went back through my AWS EC2 setup to check. The n8n process had been executing arbitrary JavaScript with access to the host filesystem since I first deployed it. That was eighteen months of production workflows running without proper isolation.
n8n 2.0’s Task Runners address exactly this problem, and the implementation is more considered than I expected. Workflow execution now happens in an isolated runner process, separate from the main n8n application. Code node JavaScript no longer has direct access to the host environment in the way it did before. For anyone self-hosting on a machine that also runs other services, this change matters more than any feature announcement this year.
The migration to Task Runners is not fully painless, and the documentation understates this. The Task Runner configuration requires environment variables that are not set by default in existing Docker Compose setups. When I upgraded to n8n 2.0, my Code nodes started throwing RUNNER_SERVER_URL errors that had no useful explanation in the official docs. The fix was setting N8N_RUNNERS_ENABLED=true and configuring the runner endpoint correctly, which I found in a GitHub issue rather than the upgrade guide.
The May 2026 release improved the AI Builder in ways that are genuinely useful if you build agentic workflows rather than just demo them. The node configuration interface for AI agents is cleaner, and the tool definition UI no longer requires you to understand the underlying JSON schema to use it. That matters because the old interface required manual JSON construction that broke in non-obvious ways when the model returned an unexpected output type. I have rebuilt the same tool definition three times on different client projects because of this, so the improvement is welcome.
Credential handling in this release is also better, though I will believe that fully when it survives a few more production deployments. The specific improvement is around how n8n validates credentials at the node level rather than only at save time. Previously, a misconfigured HTTP Request credential would pass validation but fail on execution with an error message that blamed the endpoint rather than the credential. That is the kind of bug that costs three hours when you are debugging a live client workflow at midnight.
Zapier has shipped nothing in the last six months that changes the fundamental arithmetic problem. You are still paying per task in a billing model that penalizes you for having successful, high-volume workflows. The people running complex automations on Zapier are subsidizing the product for the people running three-step Zaps once a week. n8n’s self-hosted model has no equivalent problem, which is the actual reason the platform serves 1.7 million monthly developers.
The 1,400 enterprise customer number from the release notes is interesting context for self-hosters to sit with. Enterprise adoption changes what features get prioritized, and not always in the direction that benefits people running n8n on a VPS. Task Runners, however, are a case where enterprise security requirements and self-hoster security requirements align completely. Both audiences needed workflow execution isolation, so both audiences got it at the same time.
The setup guidance improvements in the May release are the kind of thing that feels minor until you remember your first deployment. n8n’s initial setup has always had a gap between what the documentation assumes and what someone encounters on a fresh EC2 instance. Webhook URLs pointing at localhost, SSL not configured, WEBHOOK_URL environment variable unset: the May release adds clearer warnings for each of these. That does not replace the experience of hitting them yourself, but it shortens the debugging cycle for people who have not hit them yet.
n8n 2.0 and the May release are not the same kind of update. Task Runners were a structural security improvement that should have shipped earlier, and the May release is the layer of usability improvements that makes the 2.0 migration worthwhile. If you are still on n8n 1.x, the Task Runner isolation alone is a sufficient reason to upgrade. Run untrusted Code node logic on a host machine long enough and the question is not whether something goes wrong, but when.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.
