Run · founder · 6 min read

Zeabur Is Shutting Down After Two Breaches: What to Rotate and Where to Move

Zeabur says plaintext admin credentials led to a breach of 321,810 accounts and is closing by Dec 31. Here is the rotation checklist and migration plan.

Published October 24, 2026 ·

zeabur hosting security breach secrets migration

Zeabur, a hosting platform popular with people who deploy AI-built apps from a GitHub repo, announced on October 17 that it is shutting down. The reason is a second security breach in two months. If anything you built lives there, you have two jobs: change every secret it ever held, and move before the end of the year.

If you’ve never used Zeabur, skip to the last section. The lessons apply to any host.

What happened

Zeabur’s own reports describe two incidents. The first was in late August. The second, and bigger, ran October 14 and 15. Zeabur believes the attacker got credentials in August that were never fully changed, though it hasn’t confirmed that link.

Per Zeabur’s preliminary report, as relayed by several security outlets:

• About 321,810 account records were read (email, username, phone and similar).
• Roughly 3.2 million environment-variable records were read. Those are the settings where apps keep API keys, database passwords and other secrets.
• Attackers signed in as root on 101 Google Cloud servers belonging to 92 customers, and copies of 16 customer disks were attached to machines the attacker controlled.
• Commands ran inside 865 customer database containers. What was taken is not confirmed.
• Zeabur says two-factor and passkey tables were counted but not read.

Zeabur also admitted the causes: internal credentials were stored unencrypted, not every admin credential was changed after August, admin portals were reachable from the open internet, and at least one admin token dated from January 2024 and never expired.

That last list is the part to remember. This wasn’t an exotic attack. It was housekeeping that didn’t get done.

The shutdown timeline

• December 1: renewals are disabled and shared-cluster services are paused. You can restart them manually to pull a backup.
• December 31: dedicated servers and shared clusters stop.
• Zeabur hasn’t announced a data deletion date or export deadline. Don’t wait for one.

What to do this week

Assume everything in your Zeabur environment variables is public. Work through this in order.

1. Revoke at the source, then replace

Creating a new key does not disable the old one. Log into each provider and delete the old key first. Typical providers on a Zeabur project: OpenAI, Anthropic, Gemini, OpenRouter, Stripe, Cloudflare, AWS and GitHub. Zeabur’s guidance names these.

2. Change database passwords inside the database

Editing the environment variable on a hosting dashboard doesn’t change the password the database accepts. For Postgres, that means running a password change command against the database itself. If that sentence made you nervous, this is a job to hand to a developer or a freelancer for an hour. Also have them look for roles, functions or triggers you didn’t create.

3. Treat dedicated servers as compromised

If you ran a dedicated server on Zeabur, check for SSH keys you don’t recognize. Safer: rebuild it fresh somewhere else instead of cleaning it.

4. Check your bills and logs

Look at your AI provider usage and cloud bills from October 14 onward. Stolen model keys get used fast. If you connected a GitHub app, review the audit log for activity on October 15.

5. Rotate again if you already did

If you changed secrets after the August incident, change them again. The point of the second breach is that the first cleanup wasn’t enough.

6. Special cases

If you run n8n there, replace its encryption key and recreate the credentials stored inside it. If you ran an AI gateway such as one-api or new-api, revoke the upstream model keys behind it.

Where to move

You’re picking a replacement, and this is a good moment to be boring. Our reviews cover the usual options: Vercel for front-ends, Railway for back-ends and databases, Render as an all-rounder, and Netlify for static sites.

A migration order that avoids downtime:

1. Stand up the new host with new secrets. Never copy old ones across.
2. Export your database and test the restore before you trust it.
3. Point a test domain at the new host and click through the app.
4. Switch your real domain, wait a day, then delete the Zeabur project.

Do it well before December 1. Hosting rushes in the last week of a shutdown are where mistakes happen.

The lesson for anyone, anywhere

Your host holds your keys. When you pick one, ask three plain questions. Do you encrypt stored secrets? Can I rotate them from a dashboard? Do you publish incident reports? A vendor that can’t answer is a risk, however cheap.

Keep one habit regardless of host: give each app its own keys with spending caps, so a breach costs you one revocation, not a weekend. We cover the storage side in our guide on OpenCode’s key exposure.

Sources reviewed: Zeabur’s incident reports as covered by teiss, Mezha, Safeguard and Cybernews (October 20-22, 2026).