Zeabur shutting down: migrate by November 30, then services pause on December 1

With Zeabur shutting down, the date that decides whether you keep your data is November 30, 2026, not December 31. Zeabur recommends completing migration by November 30, and the same day closes account balance refund requests and security incident claims. From December 1, shared-cluster services are paused and dedicated servers shut down on their own expiry dates.

This post sets out the confirmed dates, what Zeabur has still not announced, what you have to export yourself, how the refund and claims process works, and how five replacement platforms compare on the things that actually stop a migration: persistent volumes, databases and regions.

Zeabur shutting down: the four dates in the order they bite

Founder Yuanlin Lin announced the wind-down on October 17, 2026, in a post that says Zeabur will stop accepting purchases of new dedicated servers and domains effective immediately. The follow-up notice on migration, refunds and claims sets the operational deadlines.

The sentence to take seriously is Zeabur's own warning that December 31 is the final shutdown date and does not mean every service keeps running until then. If your dedicated server expires on December 4, that is your date. Check the expiration date in your dashboard before you plan anything else, because Zeabur's notice says dedicated servers are shut down and their data deleted on their respective expiration dates, which may be earlier than December 31.

What Zeabur has not announced, and where its two posts disagree

The October 17 announcement lists three things as still to be decided: the data deletion date, the final data export deadline, and the date Zeabur Support closes. The October 22 notice then puts data deletion at December 31 for everything, and at each server's expiry date for dedicated servers. Both pages are live as of October 31, 2026.

Treat the stricter reading as the real one. There is still no published final export deadline and no published support closing date, so the only dates you can plan around are your own server's expiry and November 30. Zeabur's announcement says the same thing in plainer words: back up and migrate on the shutdown timeline rather than waiting for a data deletion deadline.

How to get your data out of Zeabur before your server expires

Zeabur published a migration guide written to be handed to a coding agent, and it is unusually specific about what the platform was doing on your behalf. Several of those things disappear rather than move, which is why an export is not the whole job.

1. Inventory the project with the Zeabur CLI: project export gives services, ports, volumes and configs, and the JSON variable list gives both your variables and the read-only ones Zeabur injected.
2. Dump each database with the official tool of the same major version as the source, then compare row counts per table after import. Zeabur's guide recommends pg_dump per database over pg_dumpall, because a pg_dumpall file carries ALTER ROLE statements that overwrite the new password on restore.
3. Copy volumes. On dedicated servers the data lives under the k3s local-path storage directory; on shared clusters, where there is no SSH access, you archive it through the CLI's service exec.
4. Download the daily database backups now. Zeabur's guide states plainly that its backups are lost at shutdown and the dashboard download links are valid for 15 minutes, so they are not a migration path.
5. Find every hard-coded zeabur.app URL in code, OAuth callbacks, webhooks and payment provider settings. Generated zeabur.app domains stop resolving, and domains you bought on Zeabur have to be transferred to another registrar yourself.

Three more things on that list are gone rather than movable: builds from source, the stored container images your deploys roll back to, and deployment history. Logs and metrics are not migrated either, so anything you need for an audit trail has to be exported before the service stops. If you are rebuilding the deploy step on another platform, a Dockerfile and a container image are the most portable form to land in.

Zeabur refunds and security incident claims both close on November 30

These are two separate support tickets and Zeabur says so explicitly. For an account balance refund, the refund is your remaining balance after final settlement, capped at the total you actually paid in cash, so promotional credit does not come back. Zeabur's worked example: top up 20, receive 100 in credit, spend 40, and the refund is 20, not 80. Payouts go to your original payment method where possible, otherwise through its partner Tremendous, and for accounts still running services through the end of December Zeabur expects payouts to complete by January 10, 2027. Requests made after November 30 have to go by email instead of a ticket.

The security incident claim is different and has no late route. Zeabur says only claims submitted by November 30 will be accepted, and it asks for the affected accounts and services, the types of leaked keys or credentials, and third-party invoices or usage records covering the incident period. That last item is the one people will not have later: if an attacker ran up spend on an API key of yours, pull the billing records now. Zeabur has said an external attacker gained unauthorized access to internal systems and some customer services on October 14, 2026, that the scope was broader than an earlier incident in late August, and that the investigation is ongoing. That is the whole of what has been published.

Where to migrate from Zeabur: compare volumes, databases and regions

Zeabur's own guide points managed-PaaS users at Railway, Render and Fly.io as closest to the experience they are leaving, and at Coolify or Dokploy if they want deploy-on-push on a host they control. Prices and limits below were checked on each vendor's own pages on October 31, 2026.

The volumes column is where Zeabur apps break. Every Zeabur volume is a ReadWriteOnce PVC on the cluster's default storage class, so anything writing to disk - uploads, SQLite, a self-hosted tool's data directory - needs a volume on the other side. DigitalOcean's App Platform documentation states that App Platform does not support volumes and points you at object storage or a managed database instead, which means a rewrite, not a migration. Render charges $0.25/GB per month for disks but attaching one costs you zero-downtime deploys and pins the service to a single instance. Fly.io volumes are $0.15/GB per month and Fly has no free tier at all for new organizations, only a trial of up to 2 hours of machine runtime or 7 days.

Databases are the second fork. Render's managed Postgres starts at $6/mo for 256 MB with storage at $0.30/GB, and its free database expires 30 days after creation with 1 GB of storage, which is a rehearsal environment and not a destination. Fly.io's Managed Postgres starts at $38/mo. Railway bills databases as ordinary services at $10/GB of RAM and $20/vCPU per month on top of a $5 Hobby or $20 Pro subscription. DigitalOcean's App Platform development databases are $7/mo per 512 MB database.

Regions are the third fork, and worth checking before price. Render lists five regions and Railway four, each of them including Singapore; Fly.io lists 17, with Tokyo, Singapore and Sydney among them. If your users sit outside North America and Europe, that is the column to read first, because moving a service to a platform that only reaches them from further away is a latency regression you will not notice until after cutover.

Skip managed PaaS entirely if you were running a dedicated server

If you were on a Zeabur dedicated server with several services and volumes, per-service PaaS pricing will cost more than the machine did, and the manifests translate directly to k3s or Docker Compose on a new host. Coolify is free when self-hosted, and its cloud plan is $5/mo for two connected servers plus $3/mo for each additional one while your apps still run on servers you rent. The catch is real: you own patching, TLS renewal, backups and the host running out of disk, all of which Zeabur was doing quietly.

The uncomfortable part: Railway had its own incident in October

Zeabur's guide names Railway first among managed PaaS options, and Zeabur is closing partly because of two security incidents. Railway published a changelog entry on October 23, 2026, saying the October 21 incident involved unauthorized access to internal Railway systems and advising all customers to revoke and replace sensitive credentials stored on Railway before October 21, remove public network access to databases, and check GitHub and container registry audit logs. Its investigation was still open at the time of writing. That does not disqualify Railway, but it does mean you should not treat a move there as a move away from the risk you just experienced, and we covered what to rotate first after the Railway breach separately.

Rotate every credential that lived on Zeabur as part of the migration regardless of where you land. Zeabur's guide notes that environment variables were stored as fully expanded plain values inline in the pod spec, not as Kubernetes secret references, so a dump of a deployment contains the effective value of every variable you set.

Do this today

Open your Zeabur dashboard and write down one number: your dedicated server's expiration date. Everything else schedules backwards from it. Then export your databases and volumes, file the refund and claims tickets before November 30, and pick the destination by your volume and region requirements rather than by feature lists.

If you want to compare hosts and databases side by side, Upfynd lists 436 products in Databases & Infrastructure and 952 in Developer Tooling as of October 2026, each with pricing and similar products on one page. Makers of migration tooling built for this wind-down can list a product for free.