> ## Content Index
> Fetch the complete content index at: https://wealthlab.life/llms.txt
> Use this file to discover other available public pages before exploring further.

# n8n 3.0 Upgrade Checklist for Self-Hosted Instances
- URL: https://wealthlab.life/n8n-3-upgrade-checklist/
- Published: 2026-10-13T00:04:56.000Z
- Updated: 2026-10-15T00:08:15.000Z
- Description: Prepare a self-hosted n8n instance for 3.0: verify the release channel, run the Migration Report, replace removed nodes, back up, stage, and test rollback.
- Author: WealthLab
- Tags: n8n, Docker, Self Hosting, Security

**Quick answer:** do not upgrade a production n8n instance to 3.0 by changing an image tag and hoping existing workflows survive. First verify what the official release channel actually serves, run n8n's Migration Report on your current 2.x instance, replace removed nodes, review changed defaults, create a restorable database and storage backup, and rehearse the upgrade on a copy. Keep the old image reference and pre-upgrade data available for rollback.

*This is a source-based operator analysis published October 13, 2026\. WealthLab did not upgrade a production n8n instance or benchmark 3.0 for this article. It contains no affiliate links.*

## Is n8n 3.0 available now?

The official [n8n 3.0 breaking-changes page](https://docs.n8n.io/changelog/v30-breaking-changes) currently says that 3.0 “has been released.” However, the official GitHub release feed checked on October 13 showed [2.42.7 as the stable release published October 12](https://github.com/n8n-io/n8n/releases/tag/n8n%402.42.7) and 2.43.4 as a prerelease; it did not expose a 3.0 release in the latest release set. The official Docker installation page likewise listed stable 2.42.7 and beta 2.43.4 when checked.

**Operator conclusion:** treat the documentation statement and the public release channels as temporarily inconsistent. Do not infer availability from an announcement page alone, and do not use an unpinned `latest` pull as a release-status check. Immediately before maintenance, confirm the exact stable tag in n8n's official GitHub releases and container registry, then record the immutable image digest you intend to deploy.

## Who needs to act?

| Current setup                       | Risk                                                               | First action                                                            |
| ----------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------- |
| Self-hosted with npm or npx n8n     | 3.0 no longer supports this runtime path                           | Move to a Docker-based deployment before the major upgrade              |
| Self-hosted Docker or Compose       | Removed nodes, settings and behavior can still break workflows     | Run Migration Report and pin the current image before changing anything |
| Queue mode                          | Manual executions move to workers; task timeout defaults change    | Review worker capacity and explicitly set required timeout values       |
| AI-agent or legacy OpenAI workflows | Older agent modes and several legacy AI nodes are removed          | Inventory node versions and migrate in 2.x before upgrading             |
| n8n Cloud                           | Docker migration does not apply, but workflow behavior changes can | Use Migration Report and test affected workflows                        |

## The highest-impact n8n 3.0 changes

### 1\. Self-hosted n8n becomes Docker-based

n8n's primary migration document says 3.0 does not provide a runnable n8n package through npm and no longer supports `npm` or `npx n8n` as the self-hosted runtime. Existing Compose operators do not need to adopt n8n's one-line installer merely because 3.0 exists. Preserve your controlled Compose deployment, explicit volumes, reverse proxy, database and backup policy.

### 2\. Removed nodes can stop executions

The removal list includes legacy Function and Function Item nodes, Cron and Interval, Read PDF, older binary-file nodes, Workflow Trigger, legacy OpenAI nodes, OpenAI Assistant, OpenAI Model, the legacy HTTP Request Tool, Manual Chat Trigger, older loaders, memory nodes and split vector-store insert/load nodes. The official page gives replacements for many of them: Code for Function nodes, Schedule Trigger for Cron/Interval, Extract from File for Read PDF, and current OpenAI or tool-capable nodes for legacy AI components.

Do not replace nodes by name alone. Save representative input and output fixtures, compare the old and replacement workflow results, and verify side effects such as outbound messages, database writes and webhook responses separately.

### 3\. AI Agent version 1 modes are removed

Version 1 of the AI Agent node and its SQL Agent, Conversational Agent, OpenAI Functions Agent, Plan and Execute Agent, and ReAct Agent modes are removed. n8n directs operators to the current Tools Agent pattern. For SQL-agent use cases, its guidance is to connect a current database tool sub-node to a recent AI Agent rather than assume an old mode will migrate automatically.

### 4\. Defaults become stricter

- **Unverified community packages:** `N8N_UNVERIFIED_PACKAGES_ENABLED` changes from enabled to disabled by default. Inventory installed community nodes before maintenance; do not turn the old default back on globally without reviewing the code and maintenance status of each dependency.
- **Task timeout:** `N8N_RUNNERS_TASK_TIMEOUT` drops from 300 seconds to 60 seconds. Find long-running Code tasks and decide whether to split, optimize, queue, or explicitly configure a justified timeout.
- **Binary storage:** the default in-memory mode is removed. Supported directions include filesystem, database and documented object-storage modes. Confirm persistent capacity and backup scope.
- **Storage path:** n8n renames `~/.n8n/binaryData` to `~/.n8n/storage` on first start. If both directories exist, 3.0 stops instead of guessing. Review bind mounts and named volumes before boot.
- **Encryption-key rotation:** rotation is enabled by default. Back up the database first and preserve the key material needed to decrypt credentials; a database copy without its encryption context is not a useful recovery plan.

### 5\. Some workflows keep loading but behave differently

Examples in the primary migration document include multi-output nodes with Always Output Data, older Gmail Trigger versions, Webflow OAuth behavior and Chat Trigger WebSocket frames. A green editor canvas does not prove equivalent behavior. Test triggers, empty-result branches, retries, authentication refresh and custom chat clients using recorded cases.

## Pre-upgrade checklist

1. **Record the baseline.** Save the exact n8n version, image reference and digest, Compose configuration, database engine/version, queue topology, task-runner configuration and current health result.
2. **Patch the current branch first.** n8n's October 1 security notice says fixed versions were 1.123.83, beta 2.42.1 and stable 2.41.4 at publication. Those are historical minimums, not today's target; use a current supported patch release for your chosen branch.
3. **Open Settings → Migration Report.** n8n 2.43 categorizes findings as Upgrade blocked, Executions fail, Behavior changes and Capability removed. Resolve blockers and execution failures first. If your current stable branch lacks the improved report, consult the official breaking-change list rather than jumping production to a prerelease merely for convenience.
4. **Export and inventory workflows.** Record workflow owners, trigger types, credentials used, community nodes, removed node types, external callbacks and expected side effects.
5. **Back up all state.** Include the database, the persisted `.n8n` data, binary storage, external object storage configuration, encryption-key material and the exact Compose/environment definitions. Keep secrets out of git and operator reports.
6. **Prove restoration.** Restore into isolated resources and verify workflow counts, credentials metadata, representative binary objects and login. A successful archive command is not a restore test.
7. **Build a staging copy.** Use synthetic or sanitized data and credentials that cannot contact customers or mutate production systems. Do not expose the staging editor publicly.
8. **Replace deprecated nodes on 2.x.** Execute old and new workflow variants against the same fixture, then compare output and side effects.
9. **Review configuration changes.** Search for removed variables, binary-data paths, runner timeout assumptions, unverified packages and queue-mode worker limits.
10. **Pin the target.** Use the exact official version tag and record its digest. Avoid `latest` for a controlled major-version change.

## Cutover and acceptance checks

- Put the system in a defined maintenance state so scheduled and webhook executions cannot race the database migration.
- Create a final consistent backup after writes stop.
- Deploy the pinned image and inspect migration/startup logs for errors rather than relying only on “container running.”
- Verify editor login, database connectivity, credentials access, webhooks, schedules, queue workers, task runners and binary-file reads.
- Run one controlled acceptance case per critical workflow class: schedule, webhook, file, database, email/chat and AI-tool workflow.
- Check that expected side effects occurred exactly once. Retrying a partially successful workflow can duplicate messages or writes.
- Watch memory, worker saturation, task timeouts, disk growth and error rate through at least one normal workload cycle.

## Rollback is a data decision, not just an image change

A database migrated by a newer major version may not be safe for an older application image. A real rollback must restore the pre-upgrade database and storage snapshot together, then start the previously pinned image against those restored resources. Do not point the old image at the already-migrated production database unless n8n explicitly documents that path for the exact versions involved.

Define the rollback trigger before maintenance: failed database migration, missing credentials, critical workflows failing acceptance, repeated worker crashes, or an error rate beyond your threshold. Also define the latest safe decision time; waiting while new 3.0 writes accumulate makes state reconciliation harder.

## Fit and non-fit

**Upgrade promptly after validation** when you need a supported 3.x capability, your Migration Report is clear, backups are restorable, and critical workflows pass staging. **Stay temporarily on a patched 2.x release** when a removed node has no validated replacement or the public 3.0 release channel is not yet verifiable. Delay is not permission to remain on a vulnerable or unsupported patch indefinitely.

**Use n8n Cloud instead of self-hosting** when your team cannot own container security, database recovery, monitoring and major-version rehearsals. **Keep self-hosting** when data placement, integrations or operational control justify that work and you have the skills to maintain it.

## What this article does not prove

WealthLab reviewed n8n's official breaking-change documentation, release notes, GitHub release feed, Docker installation page and October 1 security notice, plus an independent October 5 operator summary from Autoesta. We did not execute n8n 3.0, migrate a database, test removed-node replacements, measure resource use or verify a rollback. Exact release-channel status and migration behavior can change after publication; check the primary sources immediately before maintenance.

## Related WealthLab guides

- [Patch the October 14, 2026 n8n security update](https://wealthlab.life/n8n-security-update-october-2026/)
- [n8n VPS Requirements: RAM, CPU & Docker Sizing](https://wealthlab.life/n8n-vps-requirements/)
- [Docker VPS Production Checklist](https://wealthlab.life/docker-vps-checklist/)
- [A recovery checklist with explicit restore-evidence boundaries](https://wealthlab.life/ghost-docker-backup-restore/)
- [VPS Firewall Setup for Docker Apps](https://wealthlab.life/vps-firewall-docker-apps/)

## Sources checked October 13, 2026

- [n8n: v3.0 breaking changes](https://docs.n8n.io/changelog/v30-breaking-changes) — primary source for migration scope and actions.
- [n8n release notes](https://docs.n8n.io/changelog/release-notes) — primary source for 2.43 Migration Report behavior and dated releases.
- [n8n GitHub release feed](https://api.github.com/repos/n8n-io/n8n/releases?per%5Fpage=10) — primary release-channel evidence checked October 13.
- [n8n Docker installation documentation](https://docs.n8n.io/deploy/host-n8n/install-options/install-with-docker) — official channel and deployment guidance.
- [n8n Security Team: October 1 security update](https://community.n8n.io/t/security-update-01-october-2026/318054) — dated historical fixed-version notice.
- [Autoesta: n8n 3.0 breaking changes](https://autoesta.com/news/n8n-3-0-breaking-changes-october-2026/) — independent corroboration checked against the primary migration page.