Kubernetes & Cloud Native · 03.08.2026, 13:03 UTC
Empty sandboxes break developer experience
| Schweregrad | info |
|---|---|
| Kategorie | Kubernetes & Cloud Native |
| Quelle | Docker Blog ↗ |
| Veröffentlicht | 03.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
I work on Docker Sandboxes, so I spend a lot of time talking about isolation, microVMs, disposable filesystems, blast radii, all the good infrastructure things.
But the Docker Sandboxes feature I keep reaching for in daily use is kits.
Kits sound like a packaging detail until you try to use a sandbox for real work. An empty sandbox is a good boundary. It’s also (eventually) ephemeral and empty, and that combination means annoyance and repeated setup work.
The agent gets a clean filesystem, a baseline restricted network, and a clean credentials environment. Then it immediately needs gcloud, Java, Maven, some internal CLI, your package registry credentials, and that one skill where you distilled the tacit knowledge your team accumulated for years.
Kits are the escape hatch from that ritual. A kit lets you describe what the sandbox needs, how it should get it, what it may reach, and which credentials it can use, then apply that description when the sandbox starts.
Empty means setup work
The usual sandboxing story is security-shaped: put the risky thing behind a boundary and limit the blast radius.
Developers rarely keep using tools because the architecture diagram has a nice boundary on it. They keep using tools when the workflow is less annoying than the alternative.
A blank sandbox starts from a place developers rarely start from in practice. Real developer machines have: SDKs, package managers, cloud CLIs, shell setup, local credentials, project docs, cached tools, and configuration nobody wants to reconstruct from memory. Some of it is good engineering. Some of it …