Zeabur Is Shutting Down After Two Breaches. The Real Lesson Is the Infrastructure You Never Designed
4 min read

Zeabur Is Shutting Down After Two Breaches. The Real Lesson Is the Infrastructure You Never Designed

Brandon Groce·October 24, 2026

Zeabur, the developer platform that billed itself as "your AI DevOps engineer", is shutting down. Over the weekend the team disclosed a second security breach in two months: on October 14 and 15, an attacker used leaked internal credentials, stored in plaintext, to break into Zeabur's shared cluster and some dedicated servers, and read 3,218,965 environment variable records belonging to 321,810 accounts. Dedicated server renewals stop on December 1, and the platform is fully gone by December 31, 2026. Every app still running on it after that goes dark with it. Zeabur's own preliminary incident report is worth reading in full, and BleepingComputer has the timeline.

Zeabur brand card: Zeabur, your AI DevOps engineer Image: Zeabur, via zeabur.com

The security story is real. It is just not the whole story.

The coverage writes itself: plaintext internal credentials, admin keys that were never rotated, a second breach in eight weeks. All accurate, and security writers will have a field day with it. The angle almost everyone will miss is the one that matters most to the people reading this blog: the thing that got stolen is a design surface most of us have never once designed.

Environment variables are where a modern app keeps its actual secrets: API keys, database URLs, auth tokens, Stripe webhook signatures, LLM credentials. If you build with AI tools, you have probably never even seen most of yours. The agent writes them, the platform stores them, the deploy button hides them. When the platform leaks them, the security posture of your product was decided back at deploy time, not by anything you designed.

Think about how much craft we pour into things users see for a fraction of a second: loading spinners, hover states, page transitions. Now compare that to the effort that goes into the place where user data loses its privacy. That gap is the story.

My take

First, this is not a vibe coding failure, and anyone framing it that way is being lazy. Nothing here was caused by a prompt. A hobbyist's generated app did not leak the keys. Zeabur, a company holding paying customers' data, stored its own internal credentials in plaintext and did not rotate them. The vibe coded apps on Zeabur were the victims, not the cause. This is the landlord leaving the basement door open, not the tenants misbehaving.

Second, hosting is a product decision, and the sooner designers treat it that way, the better. The platform you click-deploy onto decides your latency, your failure modes, your upgrade path and, as we just watched, your legal exposure. You do not need to become a sysadmin. You need to know three things cold: where your secrets live, who has access to them, and how fast you can leave. That is not an ops conversation, that is product judgment.

Third, reversibility is the real feature. "Can I ship on this fast?" is the starter question. "How long would it take me to move?" is the professional question. If moving costs more than a weekend, you have a dependency dressed up as a product. Lock-in is a design constraint exactly like budget or browser support: you can accept it, but you choose it on purpose and price the risk.

Fourth, credit where it is due. Zeabur disclosed the breach, published numbers most companies would have rounded into meaninglessness, gave customers weeks of migration runway, and chose to close rather than limp along as a compromised platform. Plenty of much bigger companies have breached and said nothing. The incentives almost never point toward that kind of honesty, and Zeabur pointed there anyway.

What to do this week

  1. Inventory your secrets. Open your platform's environment variable panel and name every entry: which product it belongs to, who created it, when it was last rotated. If that list takes more than an afternoon, you have found your real security posture.
  2. Rotate everything, especially if you have ever touched Zeabur. The attacker read stored environment variables for 321,810 accounts, so treat every key that ever lived there as public. New keys first, redeploys second.
  3. Time your exit before you need it. Pick your most important app and try to move it: repo, container, another host. If that idea sounds horrifying, fix it this quarter, not during the next incident.
  4. Read Zeabur's report as a free masterclass. It shows what not to do (store internal credentials in plaintext, skip rotation) and what to do (disclose fast, publish real numbers, give people a clean exit).
  5. If you are rebuilding after the shutdown, redesign the setup instead of porting it. A forced migration is a rare chance to fix decisions you would never revisit voluntarily.

The takeaway

Deployment is design. The secrets drawer is the most consequential interface you will never wireframe, and this week it decided the fate of 321,810 accounts. The builders who come out of this fine are not the ones with the best prompts. They are the ones who knew where their keys lived and could leave in a weekend.

Building something new on managed infrastructure you can actually reason about? I keep Base44 at number one on my list of AI app builders for exactly this reason: you get hosting, auth and a real backend without adopting a stranger's basement.

Related on NewForm

Keep reading

Your Privacy, Your Choice

Control how we use your data

We use essential cookies to run NEWFORM and optional ones to improve analytics, personalization, and marketing. Choose what's okay with you.

Privacy Policy ·