n8n 2.0 ships — community nodes break on upgrade, pin your version first
- What happened
- n8n 2.0 shipped with a rewritten node API — community nodes built for 1.x fail at execution time after upgrade.
- Why it matters
- Self-hosted instances pulling `latest` break silently: workflows look healthy until they fire.
- What to do
- Pin your current 1.x version now, inventory community nodes, migrate only after each has a 2.0 release.
n8n released 2.0 this week with a rewritten node execution API. The headline gains are real: parallel branch execution and a leaner memory profile for long-running AI agent workflows.
The cost is compatibility. Community nodes built against the 1.x node API load but fail at execution time under 2.0 — the failure shows up in run logs, not at startup, so an auto-upgraded instance looks healthy until a workflow fires.
If you self-host with latest image tags, you are exposed today. Pin to your current 1.x version, inventory which of your workflows use community nodes, and check each node's repository for a 2.0-compatible release before migrating. Cloud customers are unaffected until the managed migration window opens next month.
What to do
- 1 Pin your image tag to your current 1.x version — remove `latest` from self-hosted deploys
- 2 List workflows using community nodes and check each node repo for 2.0 compatibility
- 3 Run your critical workflows once in a staging 2.0 instance before switching production
Affected tools & models
Never need to catch up again
The weekly delta — only verdict changes and act-now items. No digest filler.