Zeabur Shutdown on Dec. 31: What Founders Must Migrate After Two Breaches

Zeabur says it will close on December 31, 2026, days after reporting its second breach in under two months. A migration plan for founders: rotate before you move, rebuild what Zeabur says to rebuild, file claims early and vet the next host.

Zeabur, a Taiwan-based app-hosting platform, has set an end date: its October 19 incident report says the company will shut down on December 31, 2026, calling that “an operational decision.” The notice sits at the bottom of a long post-mortem about a breach on October 14-15, Zeabur’s second in under two months. For founders still running services there, the Zeabur shutdown turns a security cleanup into a migration with a deadline, and the order of the steps matters.

Where it stands: Zeabur called the October 19 report preliminary, said the investigation is ongoing, and said it will go on answering incident support and compensation requests, and updating the report, until it closes. No source links Zeabur’s breaches to Railway’s October 21 disclosure or to any other company’s incident.

What Zeabur disclosed, in brief

Zeabur says that “on October 14–15, 2026, an attacker used leaked Zeabur internal credentials” to reach shared infrastructure and internal systems, and that the attacker “eventually read the platform database.” It lists the scope as confirmed by logs:

Data read Scope, per Zeabur
Environment variable names and values 3,218,965 records
Accounts with profile and project details 321,810 accounts

The company did not soften the cause: “The root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext and could be used from the public internet.” The earlier breach began on August 27, and Zeabur said it confirmed that one only “after receiving a report of API key abuse on August 28 at 02:34.” This piece is about getting out cleanly.

Zeabur shutdown checklist: rotate before you move

The tempting plan is to export environment variables, paste them into a new host and redeploy. That copies possibly leaked credentials to fresh infrastructure. Zeabur’s own instructions point the other way: “Please act now; do not wait for a notification email. Credentials you replaced after the August incident must be replaced again.”

Its order for every credential is explicit: “Revoke the old ones with the service provider first, then create new ones and redeploy.” Do that, then point the new host at the new values. Here is what Zeabur’s report tells each group of users to redo:

If you use Zeabur’s instruction
Any service Replace every key and password in env vars; recreate Access Tokens
Shared cluster databases Change passwords inside the database itself
n8n New encryption key; recreate all third-party credentials
new-api / one-api Revoke upstream AI keys; regenerate tokens
GCP Dedicated Servers Treat as compromised; back up and rebuild
GitHub integration Check audit log for the App’s actions on October 15

Two lines deserve a second read. First: “Changing environment variables on Zeabur does not change the passwords inside the database.” A rotated variable pointing at an unchanged database password protects nothing. Second, for GCP Dedicated Server users: “Treat your server as compromised: Back up your data and rebuild the server. This is the most reliable way to remove backdoors.” If you are rebuilding anyway, rebuild on the destination host instead of on Zeabur.

For GitHub, Zeabur points users to their audit log for “actions by the Zeabur GitHub App from October 15, 15:05 to 18:54.” Look for clones, pushes, deploy keys or webhooks you did not create, then remove the Zeabur app from your organization once you have moved.

Collect your records before the lights go out

A closing vendor is a vanishing source of evidence. Zeabur tells users to “review usage and bills for each service from October 14, 2026 onward,” and says GCP Dedicated Server users “should go back to September 1.” Pull those records from each provider now and keep copies outside Zeabur.

Money is the second reason to move quickly. Zeabur invites users to file a support ticket for compensation if leaked keys or cloud accounts ran up charges they did not make. Its report gives no separate claims deadline. For its August incident, Zeabur asked claimants to send “daily and per-key usage statistics that clearly show the abnormal usage, affected time period, and associated charges,” which is a good template for what to gather. One caution from Zeabur’s own report: “Do not post keys or passwords that are still valid in tickets or public channels.”

Some logs simply do not exist. For the Hetzner and DigitalOcean server-management tokens that leaked, Zeabur wrote: “Neither provider keeps operation audit logs.” If your workload ran there, your own server logs may be the only record.

Use Zeabur’s post-mortem as your vetting list

Zeabur’s report is specific about what went wrong, and each failure translates into a question for the next host. These are things to ask a sales engineer or look for in security docs:

  • Do admin credentials expire? Zeabur wrote that “the admin tokens had no expiry, had not been rotated since they were created in January 2024.”
  • Are keys scoped narrowly? At Zeabur, “a key that only needed to read one storage bucket could in fact read every bucket in the AWS account.”
  • Do backups hold secrets, and where is the backup key? Zeabur said its “cluster backups contained all secrets,” with the backup key kept alongside other secrets.
  • What triggers an alert? “More than 16 hours of attack activity on October 14 triggered no alerts,” Zeabur said; a user report started its investigation.
  • Where do customer secrets live? Zeabur noted that projects which moved variables onto their own servers after August “were not part of the platform database data read this time.”

The last point is worth weighing in your choice. A host that lets you keep secrets in your own secrets manager, or on infrastructure you control, shrinks what a platform-wide breach can reach. OWASP’s guidance argues for organizations to “centralize the storage, provisioning, auditing, rotation and management of secrets,” and CISA advises replacing embedded credentials with methods “supported by centralized secret management.”

No host is breach-proof, so plan the next exit now

Moving does not remove platform risk; it resets it. Railway told its customers on October 21 that a third party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” That is a separate incident with no stated link to Zeabur, and it shows the same lesson from another angle, covered in our piece on platform risk after Railway’s breach.

Practical moves for the new setup:

  • Keep deploy configuration in your own repository (Dockerfiles, infrastructure-as-code), so the next move is a redeploy, not a rebuild.
  • Issue fresh, separately scoped keys for the new host rather than reusing any that touched Zeabur. Our secrets management runbook walks through the order.
  • Compare providers on exit cost as well as price; our guide to choosing between AWS, Azure and Google Cloud is a starting point if you are moving to a larger cloud.

Zeabur’s report also flags a small detail with a large lesson for any team winding down a service: “A deploy key for a decommissioned service remained valid four months after the service was shut down.”

Frequently Asked Questions

When is Zeabur shutting down?

Its October 19 incident report gives the closing date as December 31, 2026, describing the move as an operational decision. Until that date, Zeabur says, incident support and compensation requests stay open.

Should I rotate my keys before or after migrating off Zeabur?

Before. Zeabur told all users to replace every credential stored in their environment variables, revoking the old ones with each provider first. Copying the old values to a new host would carry possibly leaked keys with you.

Does changing my database password on Zeabur fix a leaked database credential?

Not by itself. Zeabur said that changing environment variables on its platform does not change the passwords inside the database, so shared cluster users need to change them in the database too.

Can I still get compensated for charges caused by the Zeabur breach?

Zeabur says customers who were billed for usage they did not make, on AI keys or cloud accounts, can ask for compensation through a support ticket. With the shutdown date set, filing early and keeping your provider usage records is sensible.

What should I ask a new hosting provider after the Zeabur breach?

Ask whether admin credentials expire, whether admin interfaces are reachable from the internet, where customer secrets are stored, whether backups hold secrets, what alerting exists for bulk reads, and how the provider labels what it has confirmed in an incident report.

Sources

This article is general information for founders, not legal or security-consulting advice. Incident details are as reported by the sources cited on the dates shown and can change; for breach-notification duties, talk to counsel.