Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The current official guide calls 3.0.0 early access. A version number does not establish a stable general release or an upgrade for every Cloud account.
- Self-hosted 3.0 requires a Docker-based deployment and no longer runs through npm or npx n8n. Existing Docker Compose deployments can continue using that approach.
- All users can open the migration report, but ordinary users only see workflows they can edit. Instance findings and full refreshes require an owner or administrator.
- Automatic migration saves a new workflow version. The existing published version keeps running until the new one is explicitly published; no unresolved findings does not establish business acceptance.
An available upgrade does not mean every instance should upgrade immediately
At the time of this review, n8n’s v3.0 Breaking changes page explicitly labels the release early access. This guide helps instance owners and workflow maintainers prepare. It does not verify rollout batches, Regions, prices, or actual upgrade status for every Cloud plan. Cloud teams should check their own instance notices rather than apply self-hosting requirements directly.
Record your current version, deployment method, and critical workflows before opening Settings > Migration Report. The report identifies affected workflows and configuration on your instance. A generic list of old nodes is insufficient to establish that your deployment is ready.
A clear report is useful only when you know its scope
Owners and administrators can see every workflow issue, access Instance issues, and refresh a full scan. Other users see only workflows they can edit and have no instance-issues tab. An empty report for an ordinary maintainer does not establish that the whole instance is clear; an appropriately authorized owner should consolidate the findings.
Address Upgrade blocked and Executions will fail first, followed by possible failures, behavior changes, and removed capabilities. Saving a workflow rechecks that workflow. Last updated records the latest full scan. After fixes, the responsible administrator should refresh the report and review both workflow and instance findings.
For self-hosting, prepare the deployment and recoverable data first
n8n 3.0 no longer publishes a runnable npm package. Installations using npm or npx n8n must move to a Docker-based deployment first. Existing Docker Compose deployments can retain that approach, but still need image-version, configuration, and data-migration checks. Do not use an in-place production upgrade to discover incompatibilities.
Back up the database and relevant persistent data before upgrading, and verify a recovery path. The documentation also moves binary-file storage from ~/.n8n/binaryData to ~/.n8n/storage. Having both directories blocks startup. Follow the official migration instructions and retain backups instead of casually deleting a directory.
Development CLI users should also note that different images use different Docker volumes and database migrations only move forward. Export test workflows you need before changing the CLI or image. Removing an old volume is not a general rollback method.
Why a migrated workflow may still run its old published logic
Migrate appears only for findings that support automatic rewrites, such as replacing Cron with Schedule Trigger. After confirmation, n8n saves a new version. A published workflow continues using its existing version until you select Publish. Choose Skip publishing if you want to review the result in development first.
Removed nodes cause affected workflows to fail, and affected published triggers will not activate. AI Transform is removed without automatic migration. If it already contains generated JavaScript, the migration report can move that code into a Code node. Without generated code, replace its processing manually. Do not assume every legacy node has a one-click upgrade.
Use controlled test inputs to check outputs, branches, and trigger conditions before publishing. The migration tool handles node changes; it does not guarantee the business result remains correct. Saving, migrating, passing tests, and publishing are separate states.
Check changed defaults and clients even when nodes show no error
Always Output Data now creates an empty item only when all outputs have no data, which can change downstream behavior for nodes with several outputs. Chat Trigger in Using Response Nodes mode now sends JSON WebSocket frames. The official guide requires @n8n/chat 1.31.0 or later; custom clients must also handle the new message types and heartbeat contract.
Slack API credentials used by SlackTrigger must include a Signing Secret. Missing it affects publication or trigger activation after a restart. An authorized administrator should configure it using the official instructions. Keep signing secrets out of support tickets, articles, and test samples.
Review instance limits too. Default decompressed data drops from 2 GiB to 256 MiB, and the entry limit drops from 5,000 to 1,000. If a new limit causes failures, inspect the input and capacity requirement instead of treating the problem as a general network or proxy fault.
What to verify before release, beyond resolving the report
After workflow and instance fixes, an owner or administrator should refresh the report. Other users can reload it to review workflows they have saved. Even when neither tab has unresolved findings, check the official breaking-changes list for changes the tool cannot detect before following your team’s upgrade plan.
Retain pre-upgrade backups, the target version, critical inputs and outputs, and the responsible owner’s approval. Verify the actual published workflow version, scheduled and Webhook triggers, and any required external clients. Use an established recovery plan if the new environment fails; do not assume an older image can read a migrated database.
No instance upgrade, external connection, or credential operation was performed for this guide. A proxy cannot restore removed nodes, replace Docker deployment, or change product eligibility. Investigate network paths separately only when there is specific DNS, TLS, proxy-authentication, or timeout evidence.
Sources
Frequently Asked Questions
Does marking a workflow Won’t fix repair it?
No. It counts that finding as resolved and removes it from open findings; Reopen reverses the classification. It does not replace nodes or change execution logic, so it cannot prove production compatibility.
Does the exported CSV show migration progress for the entire instance?
The export contains only workflows and issues visible to the current user. An ordinary user’s export is not an instance-wide audit. Instance totals repeat on every row and must not be added together.
Is an issue resolved after notifying its workflow owner?
No. Administrator notifications require configured instance SMTP and an owner email address. Notified remains unresolved. Judge progress by the actual fix, a fresh scan, and test results.