Migrating off Zeabur: hand this guide to your coding agent
We've written up how Zeabur runs your services and what it has been doing for you, in a document built for coding agents. Your agent reads your current setup and works out with you where to move.
Zeabur TeamThis article is also available in 繁體中文, 简体中文, 日本語, Español, and Bahasa Indonesia.
TL;DR: Open a coding agent such as Claude Code or Codex and paste the line below. If you don't have a coding agent, open a ticket through Zeabur Support with your services and expiry date, and we'll help you migrate.
Read https://zeabur.com/blogs/migrate-from-zeabur.md and help me migrate my services off Zeabur.The agent takes stock of your services, asks about your needs, recommends options, and walks you through the move. It asks you before every step that changes anything. To see what the agent reads, switch to the AGENT view at the bottom of the page.
This guide will be updated as the shutdown progresses and as you report issues. Have your agent read the latest version again before you start.
Per the shutdown announcement: from December 1, dedicated servers shut down on their own expiry dates; shared-cluster services are suspended from December 1, and you can still resume them manually to back up your data; on December 31 all services stop. Plan around your own expiry date, and don't wait until the last day.
Why hand it to an agent?
Every project, skill level and budget is different. Some people just want their site to stay up, some want full control of a server, and some want something that keeps Zeabur's "push and it's deployed" workflow. A single fixed tutorial can't serve everyone.
Your agent can read your code and log in to your server, so it sees far more than an article can assume. We documented the parts it can't work out on its own:
- Which Kubernetes objects your services are on Zeabur, and where data, images and variables live
- What Zeabur has been doing for you that someone has to take over after the move
- Where migrations commonly go wrong
The agent recommends where to move and which tools to use based on your situation. You make the final call.
Which kind of user are you?
| Type | What happens to the machine | How the agent reads the current state |
|---|---|---|
| Dedicated server rented on Zeabur | Belongs to Zeabur's cloud account and is deleted after expiry. Disk data is not kept. | SSH into the server and read k3s directly |
| Your own server (bound to Zeabur) | Stays with you, but the Zeabur components on it stop working | SSH into the server and read k3s directly |
| Shared cluster | Services are suspended, then stopped | No SSH; through the Zeabur CLI and dashboard |
The root password for a dedicated server was emailed to you at purchase. If you've lost it, reset it in the dashboard, or log in with npx zeabur@latest server ssh.
What has Zeabur been doing for you?
After the move, each item below needs a new owner. The agent accounts for every one of them when it plans:
| What Zeabur did | After Zeabur shuts down |
|---|---|
| Builds images from your Git source | You need a Dockerfile or the new platform's build feature |
| Stores images in Zeabur's registry | Pulls fail, and services won't start after a restart |
| Deploys on push, deployment history, one-click rollback | You need CI/CD or a platform with these features |
*.zeabur.app domains | Stop working; switch to your own domain |
| Issues and renews HTTPS certificates | You need a reverse proxy or the platform's certificate feature |
Connects services via .zeabur.internal | Replace with the new environment's networking |
| Injects variables across services in a project | Carry over the actual values |
| Backs up databases daily | Backups disappear too; export them and set up your own |
| Logs, metrics, crash and resource alerts | You need your own logging, monitoring and alerting |
| Team members and permissions | Set them up again on the new platform |
The two most common failures are images and injected variables. Missing images only blow up after Zeabur shuts down; missing variables break your app's database connection the moment you move.
Before you start
- A coding agent, such as Claude Code or Codex
- Node.js on your computer, and the Zeabur CLI logged in with the account that owns the project:
npx zeabur@latest auth login - For dedicated servers: SSH access to the server
- Permission to change your domains' DNS. Domains bought on Zeabur can be transferred out from the Dashboard
- Your expiry date, and a window when downtime is acceptable
Let the agent use the CLI already logged in on your computer. A Zeabur access token has access to your whole account; pasting it into a chat is handing over the account.
How does the migration go?
- Inventory: the agent lists each service's source, domains, data size, and whether its image can be exported.
- Choose a destination: based on your comfort level, budget and the features you care about, the agent compares two or three directions, such as a managed platform like Railway, a self-hosted platform like Coolify, k3s, or Docker Compose.
- Plan and dry run: set up the services in the new environment, copy the data once, test the main features, and actually restore a backup.
- Cutover: once you agree, suspend the apps on Zeabur, sync the data one last time, and change DNS yourself.
- Handover: the agent explains how to deploy, back up and roll back in the new environment.
We moved a live Django site (PostgreSQL, Redis, the app, nginx) this way: row counts matched across all 28 tables, and the cutover took about 6 minutes of downtime, about 3 of which were spent waiting for certificates.
Stuck?
Have the agent summarize the current state and error messages, then send them to us through Zeabur Support along with your expiry date so we can gauge the urgency.