What nine breaches in one month taught us, how Miget is built, and the design choices we made after reading every RCA.
In October 2026, at least nine AI and developer platforms were breached. Wiz called it Black October. Zeabur, Railway, Northflank, Fireworks, Lightning AI, OpenCode, Warp, Andromeda, and CommandCode all had to tell their users something nobody wants to say.
We run a PaaS. Your apps, databases, and environment variables live on our infrastructure, so the central lesson is simple: read every public report closely, then use it to harden the parts that matter most. This post focuses on what we learned, how Miget is isolated, and how we watch for trouble.
One thing up front: no platform is immune, including ours. The thesis of this post is that we can still keep the blast radius small, make the dangerous paths boring, and be honest about where the risk lives.
Credit where it is due
Several of these teams published detailed root cause analyses within days, while still cleaning up. Zeabur did it while announcing the company is shutting down. That’s hard to write, and it is the only reason the rest of us can learn from it. Those reports help bridge what happened and what we can do next. Most of these mistakes are ones every infrastructure team has been one bad week away from making.
What happened
Zeabur's RCA describes a plaintext, non-expiring cluster admin token in a private config repo, with the admin API reachable from the internet. Some credentials from an earlier incident had not been rotated. The attacker read environment variables throughout regions, ran commands inside database containers, pivoted through backups into a secrets manager, joined the internal network, and read the platform database. Nothing alerted for about 36 hours. A user report found it.
Railway's preliminary report describes a privilege escalation in shared build infrastructure that exposed CI credentials, enough to decrypt part of the encrypted environment variable store. The attacker searched for AI API key names. Railway is moving builders to single-tenant.
Northflank told users to assume all environment variables were decrypted, and AI keys were abused. At Fireworks, environment variables were exposed inside evaluation jobs. Lightning AI, OpenCode (a legacy system holding provider keys), Warp (via a third-party vendor), Andromeda and CommandCode round out the list.
Wiz explained the speed. Stolen AI keys were validated within roughly 30 minutes, from the breached vendor's own infrastructure, then resold. Two keys ran up more than $100k in Bedrock usage. The attacks looked like agent swarms: known techniques, chained fast and in parallel.
The pattern
The target is stored customer secrets, AI keys first. A database dump needs a buyer. An AI key with no spend limit is cash the moment someone validates it.
The way in is a valid credential or the system that runs customer code. A long-lived token in a repo, a build system, an evaluation job. These places are trusted by design, and that trust is what gets borrowed.
The amplifier is one internal place that can read every tenant's secrets. One foothold turns into everyone.
Detection failed because the attacker looked legitimate. Real credentials and real API paths do not trip alerts tuned for "something weird".
So the useful questions for any platform are: what runs customer code, what can it reach, what single identity can read everything, and would anyone notice? This post answers those questions for Miget because they define the risk we are trying to reduce. With that frame in place, here is how Miget is built.
How Miget is built
Every workload and every build runs in its own microVM. Each app, worker, and build gets its own guest kernel on Kata Containers. A container escape lands inside a throwaway VM, not on the host and not next to another customer. That means one compromise is far less likely to become a platform-wide incident, which is the payoff of this model: smaller blast radius and less cross-tenant risk. More on the model in What Is a MicroVM? and gVisor vs Kata Containers.
We patch the kernel your app runs on. Because every workload has its own guest kernel, we ship kernel security fixes to it ourselves instead of waiting on a host OS cycle. When a kernel CVE lands, we build, test on our dev cluster, and roll the fixed kernel across the fleet, so fixes reach your workload faster.
When a critical kernel CVE lands, like the 9.8 CVSS Linux TCP flaw this October, we restart your app onto the patched kernel on your behalf. Security goes first.
Host maintenance without downtime. Running workloads can be live-migrated between hosts, so taking a machine out for patching does not mean restarting your app. The payoff is keeping the fleet patched without forcing your customers to absorb the interruption, so maintenance stays safer and less disruptive.
Builds are ephemeral. Each build gets a fresh microVM that is gone when the build finishes. No long-lived shared builder sits between jobs.
Apps are isolated by default. Each tenant is isolated on the network, and app-to-app traffic is off until you turn it on. The payoff is that one app cannot casually reach another before you allow it, which keeps the blast radius smaller if something goes wrong.
We review and reproduce every platform change. Infrastructure is managed declaratively from Git and tested on a separate dev cluster before it reaches production. No one changes anything by hand on a production box.
Our cluster control plane is not on the internet. At Zeabur, the attacker started with an admin API that answered from anywhere. Ours does not answer from the internet at all. The Kubernetes API in every region has no public address. Our engineers reach it over a private network that requires company sign-on and an approved device, and that network opens only the API port. The control-plane servers accept SSH only from a short allowlist of admin sources, and no workload holds the private key that signs cluster credentials. The payoff: a leaked credential on its own is not a way in, because there is no public door to use it on.
The API does not hand secrets back. Basic Auth credentials and the Git and registry credentials you store with us are write-only. You can set and replace them; the API never returns them. That way, fewer secrets can be exposed through the API, making accidental reuse less likely and reducing the chance of leakage spreading. Those are the platform-wide controls. Next are the security options you can turn on today.
Security you can turn on today.
- Private networking (VPC) and VPN. Give your workspace its own private network and connect it to your office, your own cloud, or your tailnet over VPN. Databases and internal services never need a public address, which lowers exposure.
- Private apps. Mark an app private, and it has no public ingress; it's reachable only from your other apps so that you can keep internal services out of sight.
- Basic Auth at the edge. Put a staging or internal tool behind a password with one setting, enforced before traffic reaches your app.
- Hardened base images. Build on Docker Hardened Images with a single build option: minimal, regularly patched bases with far fewer packages to exploit. The payoff is a smaller attack surface and less to maintain.
- An activity log for every app. Deployments, configuration changes, and audit events in one feed, from the dashboard or the API.
- EU data residency. Run in our Warsaw region, and your apps and data stay in the EU, so residency stays simple and the operational choice stays clear. With those options covered, the next section shows how we keep builds narrow.
Builds hold little and reach little
Reading the RCAs, builds stood out as the place every PaaS has to treat as hostile. Our build design follows one rule: the thing that runs untrusted code holds as little as possible, for as short a time as possible, and reaches as little as possible. The payoff is less room for compromise to spread.
Build-time copies of secrets are not retained. Values from your environment exist inside a build for the length of that build. Build records keep what you need to debug a build, not the values it ran with.
Builds can only reach what they need. Build microVMs reach the image registry, DNS, and the public internet for dependencies. Internal platform services are not reachable from a build.
Registry credentials are scoped. Builds push with credentials scoped to that tenant's own project. The credentials clusters use to pull images can only pull.
Build tooling is pinned and mirrored. Third-party images in our build pipeline are pinned by digest and served from our own mirror, so an upstream tag change does not change what runs in your build.
Git credentials are short-lived. The credential a build uses to fetch your code is issued for that build and deleted when it finishes.
Coming next: build-time variables you choose. You will be able to mark exactly which variables a build receives, so your Stripe key never has to sit next to npm install. We will post when it ships. That matters because builds should hold little and reach little, as this section explains.
Would we notice? miget-inspector
Isolation limits what an attacker can reach. It does not tell you someone is there. In Black October, detection was the common failure: attackers used valid credentials, and at Zeabur it took about 36 hours and a user report. So we also watch what workloads do while they run, because the goal is noticing abuse sooner.
miget-inspector is our in-house runtime threat detection, enforced in every production region. Every workload is inspected as soon as it starts, and every running app keeps getting rechecked, not only new ones, so suspicious behavior is caught sooner.
It looks at how a workload actually behaves and combines fast heuristics with an AI classifier to separate normal apps from cryptominers, hidden proxies, and tunnels: the things network signatures miss. It also catches the other side of Black October: unauthorized AI API relays that resell pooled or stolen provider access, including bots that impersonate web sessions of services like Grok. When a workload is judged malicious with high confidence, it's isolated automatically, and our team is alerted. Anything less certain gets a closer look over time and a human in the loop, never an automatic shutdown on a guess.
It is one layer, not a guarantee. But it answers "would we even notice?" with a better yes than logs alone, which is the point. We are considering open-sourcing it.
What you should do, on any platform
Scope your AI keys. One key per app and per environment. Set spend limits or budgets with the provider and turn on usage alerts - a leaked key with a 100k story above.
Rotate after any vendor incident. If a platform, CI provider, or tool that held your keys reports an incident, rotate, even if they say you were not affected. Do the AI keys first.
Do not give build information they do not need. Builds compile code and install dependencies. They rarely need payment keys, database passwords, or model API keys. Keep those runtime-only wherever your platform allows.
Prefer short-lived credentials. Where a provider offers OIDC, workload identity, or expiring tokens, use them instead of static keys.
Treat the bill as a security signal. Unexpected AI usage is often the first sign a key leaked.
Found something? Tell us
If you find a security issue in Miget, email privacy@miget.com before posting it anywhere. We read every report and will get back to you.
Closing
Black October was a bad month for people who build platforms similar to ours, and a worse one for their users. The lesson we took is the same throughout this post: the places that run customer code, and the identities that can read every tenant's secrets, deserve the most paranoia, because attackers go there first.
We will keep building in public. If you have questions about how something on Miget works, ask us on Discord or read the docs.