Zeabur is shutting down: how do I move my app and rotate my keys before Dec 1?
Rotate first, then move. Zeabur's preliminary report says an attacker read the platform database on Oct 15, including 3,218,965 service environment variable records (names and values) across 321,810 accounts, and tells every user to "replace every password and key stored on Zeabur, even if you already replaced them after the August incident." Its migration guide says variables Zeabur injected across services have to be carried over as actual values. Rotate before you copy them, or the new host starts with credentials that are already out.
The dates, per Zeabur's Oct 17 shutdown post: purchases of new dedicated servers and domains stopped that day. From Dec 1, services on shared clusters are paused (you can restart them manually to back up data), and dedicated server renewals are disabled, so each server shuts down on its own expiry date. By Dec 31, all dedicated servers and shared clusters stop.
What the breach read, per Zeabur
Oct 14–15 (UTC): the attacker used leaked Zeabur internal credentials to reach the shared cluster in 9 regions, 101 GCP dedicated servers and internal systems, then read the platform database between 16:10 and 16:47 on Oct 15. Zeabur's stated root cause: "long-lived admin credentials were stored in plaintext and could be used from the public internet."
Confirmed in the platform database: 3,218,965 environment variable records, 321,810 accounts (email, username, phone number and project data), 566 zSend API keys in plaintext. All 11,536 platform access tokens were revoked.
On the shared cluster, environment variables and secrets of all services were read (partly confirmed; regions without logs are treated as leaked), and the attacker ran read commands inside 865 database containers, mostly n8n and PostgreSQL.
Intent, in Zeabur's words: the attacker "was mainly looking for API keys they could use directly, especially keys for AI services." It searched the obtained data for API keys and private keys, read credentials in n8n and new-api/one-api at scale, and tried to call Amazon Bedrock with Zeabur's own AWS keys (every attempt failed).
Projects that moved their environment variables to their own dedicated server after the August incident are outside the platform database read. If the host itself was compromised, Zeabur says its credentials still need replacing.
Zeabur's status page marked the incident resolved on Oct 20 when it published the report; it says the investigation is ongoing and "Exposed data may still be misused."
Why rotate before migrating
A leaked key works from anywhere, now. Moving the app doesn't change the key; rotating does.
The migration guide notes that variables Zeabur injected across services must be carried over as actual values. If those are the pre-breach values, the move preserves the leak.
Zeabur says to revoke with the provider before creating the replacement, and to check bills from Oct 14 onward (GCP dedicated servers from Sep 1). It accepts compensation requests for third-party charges through Zeabur Support.
Values you set on Zeabur after rotating are stored there until it closes. Zeabur has not announced its data deletion date. Delete what you no longer need once the new host is live.
An order that matches the risk
Zeabur did not publish an order. This one is ours, built from what it says the attacker looked for.
AI service keys. OpenAI, Anthropic, OpenRouter and similar, including the upstream keys behind any new-api/one-api instance. These were the stated target. Revoke each in the provider's dashboard, create a new one, set a spend limit if the provider offers one, update the variable and redeploy.
Stripe and other payment keys. A Stripe secret key can create charges, issue refunds and read customer data. For a value you know was read, rotate with the shortest expiry you can deploy within. See rotating a leaked Stripe key without breaking webhooks.
Database credentials. Per Zeabur, "Changing environment variables on Zeabur does not change the passwords inside the database." Change the password in the database itself, then the variable. If the database stores your users' password hashes, sessions or tokens, revoke and regenerate those too. On PostgreSQL, check for roles, functions, triggers, scheduled jobs or extensions you don't recognize; Zeabur's advice if in doubt is a new database with only the data imported.
OAuth client secrets, signing and encryption keys. OAuth client secrets, JWT and session signing secrets, webhook signing secrets. Changing a session secret signs everyone out, so do it once, in one deploy. For n8n, replace the encryption key and recreate every third-party credential: Zeabur found the key in an environment variable on 602 of the 607 n8n instances it checked.
Cloud keys, GitHub and Zeabur's own tokens. AWS, GCP and similar keys; check GitHub's audit log for actions by the Zeabur GitHub App on Oct 15, 15:05–18:54 UTC (unexpected clones or pushes, new deploy keys, modified webhooks); recreate Zeabur access tokens and zSend keys if you still need them for the move.
Then migrate, carrying the new values. On a GCP dedicated server, Zeabur says to treat the server as compromised: back up your data and rebuild, which it calls "the most reliable way to remove backdoors."
Zeabur's migration guide
Zeabur publishes Migrating off Zeabur: hand this guide to your coding agent, with a Markdown version for coding agents. It lists what Zeabur did for you that needs a new owner after the move (image builds and registry, *.zeabur.app domains, HTTPS certificates, .zeabur.internal networking, injected variables, daily database backups, logs and alerts), and says the two most common failures are images and injected variables.
Two lines from it worth following: let the agent use the Zeabur CLI already logged in on your machine, because "A Zeabur access token has access to your whole account; pasting it into a chat is handing over the account"; and the Markdown version tells the agent never to print secrets and to treat zeabur variable list and zeabur project export output as secret. The guide says it will keep being updated, so have the agent read the latest version before you start.
Read each provider's usage and billing from Oct 14 onward for calls you didn't make. Zeabur's report lists indicators of compromise (IP addresses, an SSH key comment @zeabur-pentest, an AWS client user agent) to search for in your logs.
Ship Check Kit · $29
Rather not run it by hand?
The Ship Check Kit has your coding agent find every key that ever left the server (SC-SEC-01 for git history, SC-SEC-02 for the browser bundle) and then confirm each old value is actually revoked, not just replaced (SC-SEC-03, which fails while an old value still gets anything but a 401 or 403). Three of 44 launch checks, each with the evidence and the fix.
