deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

n8n 3.0 beta lands with breaking changes as 1.x support ends December 31

n8n has released a 3.0 beta that removes legacy nodes, tightens defaults and offers no rollback. With 1.x support ending December 31, workflow owners should run the built-in Migration Report now.

n8n 3.0 beta lands with breaking changes as 1.x support ends December 31

n8n, the open-source workflow automation platform, shipped a beta of version 3.0 on October 27, 2026, according to a write-up on dev.to. The release introduces no headline features — instead it strips out legacy components and tightens default security settings, which makes it a breaking upgrade for many existing workflows. A stable release is planned for early December, and support for version 1.x ends on December 31, 2026.

What breaks in version 3.0

The dev.to post, drawing on n8n's published breaking-changes documentation, highlights the changes most likely to affect running instances:

  • Removed nodes, among them Function, Function Item, Item Lists, Cron, Interval, Read PDF, the legacy OpenAI node and version 1 of the AI Agent node. A published workflow relying on one of these will not activate once 3.0 starts, so the trigger no longer fires.
  • Gmail Trigger versions below 1.4 now ignore draft emails unless explicitly enabled, and each poll checks a maximum of 10 messages by default.
  • Slack Trigger workflows stop receiving events until a signing secret is added to the Slack credential.
  • Self-hosted installations must run on Docker; setups launched via npm or npx are no longer supported.

The upgrade path has its own constraints. Instances cannot jump straight from 1.x to 3.x — they have to move through 2.x first — and the jump to 3.x is one-way, with no rollback to 2.x on Cloud or self-hosted deployments. According to the announcement cited in the post, 3.0 applies to the free self-hosted Community edition as well as Cloud and paid plans, so the cost is migration time rather than licensing. Version 2.x will keep receiving security and critical fixes for 12 months after the stable release.

The Migration Report

The main tool for the transition is the Migration Report, found under Settings > Migration Report on any instance running version 2.39 or later. As described in the migration tool documentation, it provides a progress bar showing how many workflows are compatible, an impact rating for every issue ranging from "Upgrade blocked" to "Capability removed", and run counts plus last-run dates for each workflow so the busiest ones can be prioritised. Where possible it offers a Migrate button that rewrites nodes automatically — Cron to Schedule Trigger, for example. The currently published version of a workflow keeps running until the migrated replacement is published. The automatic migration handles node changes only, so outputs still need manual verification.

A practical upgrade order

The dev.to post suggests a sequence: confirm the current version (the Updates section of Instance settings in the Cloud console, or the About screen in the editor), move 1.x instances to 2.x before December 31 with a full database backup in hand, then update to the latest 2.x and open the Migration Report. Fix high-traffic flagged workflows first and mark anything that has not run in a year as not worth the effort. Self-hosted users on npm or npx should switch to Docker while still on 2.x. After the stable December release, the recommendation is to upgrade a test copy, run the three busiest workflows on it, and only then upgrade production. As a rough estimate, the post suggests 15 to 30 minutes per workflow the report can migrate automatically, including a test run, and one to two hours for each workflow that needs a manual rebuild.

Why it matters

The danger with this upgrade is silence, not crashes. As the dev.to post points out, a scheduled report can stop because the Cron node no longer exists, or renewal reminders can quietly miss messages because the Gmail Trigger now polls only 10 emails — and in a small business whose original builder has moved on, nobody may notice for weeks. Between the December 31 end of 1.x support, the mandatory stop at 2.x, and a one-way door into 3.0, preparation is time-sensitive. The Migration Report turns an abstract list of breaking changes into a ranked, per-workflow checklist, and running it on 2.x changes nothing until a migrated workflow is published — which makes now, rather than December, the cheap moment to look.

  • #n8n
  • #workflow-automation
  • #self-hosting
  • #docker
  • #open-source

Related posts