Container isolation: more than security theater
How we built real isolation between apps — and why it matters more than most people think.
Every hosting provider says they isolate your apps. Most don't — not really. They put your container on a shared kernel with shared network and storage resources, and hope the namespaces hold. We built isolation differently. Here's how.
Why isolation matters
If you're running a password manager and a public blog on the same host, you need real isolation. A vulnerability in one app shouldn't be able to access another app's memory, storage, or network traffic. Shared-kernel containerization doesn't provide this guarantee.
Our isolation stack
We use a three-layer model: gVisor for kernel isolation (each app runs on its own userspace kernel), Cilium for network isolation (eBPF-based policy enforcement at the network layer), and encrypted persistent volumes with per-app keys. Even if an attacker gets root in your container, they can't access another app's data.
The performance cost
Real isolation isn't free. gVisor adds ~15% overhead on syscalls. Encrypted volumes add ~5% I/O latency. We accept these costs because they're the right trade-off. A hosting platform that sacrifices security for 5% better benchmark numbers is making a bet against its users.
What this means for you
You can run Vaultwarden and a public WordPress instance on the same CodeHost account with confidence. They're on different virtual kernels, different network segments, and different encrypted volumes. No shared attack surface. No cross-contamination risk.
We publish our isolation architecture publicly because we believe you should be able to verify our claims yourself. Security through obscurity isn't security.