Zeabur Is Shutting Down: The Complete Move-Out Checklist Before December 1

Zeabur announced on 17 October 2026 that it is shutting down after a second security breach on 10/14 — broader than the August incident — compounded by slowing growth as AI makes deployment ever easier. The timeline is tight: new server and domain sales stop immediately and balance refunds are open; on 1 December the shared clusters pause (you can still power them on manually for backups) and dedicated servers stop renewing, closing on their expiry dates through December; on 31 December everything ends, with the data-deletion date still unannounced. If your team runs anything on Zeabur, treat 1 December as your real deadline — this guide is the complete move-out checklist.

Step 0 — assume your secrets are already leaked

After a breach, every API key, database password, and token you ever pasted into Zeabur's environment variables must be treated as compromised. Before you move anything, inventory every secret you stored there; during the move, rotate each one — revoke the old, issue a new one, and never copy a leaked value into your new host. Doing this after the migration is too late: the window between 'breach announced' and 'keys rotated' is exactly when abuse happens.

The n8n trap: your encryption key is the whole move

If you run n8n on Zeabur, the single most important file is not your workflow exports — it is the encryption key (N8N_ENCRYPTION_KEY, or the .n8n/encryptionKey file). n8n encrypts every stored credential with it. Export your workflows, sure — but if you lose the key, every credential in them is unreadable forever and you will re-enter every single connection password by hand. Copy the key somewhere safe first, set it on the new instance before importing anything, and verify one old credential actually decrypts before you touch anything else.

Workflows can be re-exported. The encryption key cannot. Whoever moves your n8n instance must name the key's location before the move starts — if they can't, stop.

The three things everyone forgets

• Uploaded files and volumes — Zeabur stores these separately from your code; export every volume before the cluster pauses, because a redeployed app with empty storage looks 'migrated' until the first user uploads something.
• Domains and DNS — your custom domain's DNS records point at Zeabur; plan the cutover (lower TTL the day before, repoint after smoke tests) or you'll discover it on 1 December with your site down.
• Webhooks everywhere — Stripe, LINE, Meta, Telegram, GitHub all hold your old Zeabur URL. Every webhook endpoint must be re-registered at the new URL and test-fired; a webhook nobody re-points is a silent failure.

A sane order of operations

Inventory everything (apps, volumes, domains, webhooks, secrets) → stand up the new host in parallel (a small VPS or another PaaS — never migrate onto the same account that was breached) → rotate every secret → move n8n with its encryption key and verify decryption → copy volumes → deploy and smoke-test on a staging URL → repoint DNS with TTL lowered → re-register and test-fire every webhook → keep the Zeabur instance powered on for two weeks as a fallback, then export final backups and let it go.

No engineering hands? This is exactly what we do

A Zeabur move is a fixed-scope, deadline-driven engineering job — the exact shape our escrowed acceptance gate was built for. Post your stack (even roughly: 'two n8n instances, one Next.js site, one Postgres'), and a vetted expert replies with a concrete migration plan and fixed quote. Payment sits in escrow held by a licensed payment institution and releases only when the acceptance checklist passes: site reachable, webhooks returning 200, old n8n credentials decrypting, old keys revoked. The deadline is 1 December — the busiest window will be the last two weeks of November, so earlier is cheaper.