n8n 3.0 enters beta: self-hosting moves to Docker, so test upgrades

This is an optional beta with operational changes

n8n announced its 3.0 beta on October 27, 2026, allowing organizations to opt into testing deployment and workflow-default changes. Stable release is planned for early December, rather than a guaranteed date. This October 28 report distinguishes a beta trial from upgrading a customer-facing system.

Teams using npm or npx self-hosting, large files, long-running Code tasks or community packages should inventory their deployment first. Version 3.0 supports Docker for self-hosting; Kubernetes/Helm follows its applicable deployment path. Discovering the installation method only after a failed workflow is avoidable.

The screenshot is version 3.0.0, not evidence of production compatibility

Friday Works ran the n8n 3.0.0 container in a separate test environment on October 28 and opened Migration report → Instance issues. The original screenshot retains Version 3.0.0 and shows four instance-default warnings. There are no customer workflows; 0 of 0 compatible is not validation of an organization’s real processes.

Migration Report already exists from 2.39 for upgrade preparation. This report neither substitutes a 2.39 screenshot for 3.0 nor claims the report first appeared in 3.0. Checking the interface and version does not establish successful database migration, restoration or execution with real credentials.

New defaults can interrupt existing jobs

The 3.0.0 report shows the task-runner timeout default falling from 300 to 60 seconds. Longer Code tasks may need a deliberate N8N_RUNNERS_TASK_TIMEOUT setting. Understand the task before increasing a timeout; unlimited execution is not a general remedy.

Compression defaults fall from 2 GiB to 256 MiB of decompressed data and from 5,000 to 1,000 ZIP entries. These are default changes, not proof that every existing file will fail. Test representative files and record expanded size rather than only compressed input size.

Unverified community packages stop loading by default unless N8N_UNVERIFIED_PACKAGES_ENABLED is explicitly configured otherwise. Review package authors, versions and necessity before retaining that permission. Verification status does not remove the need to assess a node’s access to credentials and data.

Import from URL is also removed from the editor. Internal instructions using that action need updating rather than directing users to a missing control.

Security and queue behavior depend on deployment conditions

The announcement describes changes to encryption-key rotation, Slack signing secrets and SSRF-related defaults. Server-side request forgery involves inducing a service to request an unintended address. An expanded blocklist matters only when the applicable protection is enabled; do not infer that every installation automatically blocks all unsafe network access.

Queue deployments should review manual-execution placement and binary-data storage. In-memory binary handling no longer serves the old role; use supported filesystem or external storage appropriate to the architecture. Verify main and worker behavior, encryption keys and shared-data access. A working editor does not validate those execution paths.

A backup needs a demonstrated restore path

n8n warns that returning from 3.0 is not a simple downgrade; restoring a suitable backup is required. Friday Works recommends a separate trial, retaining the database, configuration, encryption keys and necessary binary data, then actually testing restoration before a production window.

Version 2.x receives security and critical fixes for 12 months after 3.0 becomes stable, not after the beta date. For installations still on 1.x, the vendor states support ends December 31 and advises going through 2.x first. Check the official schedule rather than skipping a servicing branch because a beta exists.

Include representative webhook, file, Code, Slack and community-node workflows with expected outputs and named reviewers. A passing upgrade preserves business results, worker and scheduling behavior, credentials and a proven recovery path. Until those conditions are met, keep the trial bounded.