Which Isolation Boundary Do You Need?
A devcontainer, a git worktree, a Kubernetes sandbox, a microVM, or a full cloud development environment. Five questions, asked in order of how decisive they are, and you stop at the first one that settles it.
The tool below is optional. The complete tree is written out in text further down the page and needs nothing but a browser.
The Five Questions, in Order of Decisiveness
Most comparisons of these five options start with features. Features are the least decisive thing about them. These are the axes that actually eliminate options, ordered by how much work each one does.
1. Is the code trusted? This is the single biggest fork and it is the one people skip. Code you wrote, or that a colleague reviewed, is a different object from code a model generated and nobody has read. A human running a test exercises judgment about what they execute; an agent installing dependencies and acting on a README it just fetched does not. That difference is what pushes you past a container and toward a microVM, and it overrides every answer below it.
2. Does it need its own kernel, nested virtualization, or a non-Linux operating system? A hard technical disqualifier. Kernel module work, anything that itself runs a hypervisor, and Windows or macOS targets cannot be served by a shared-kernel container at all, so this question ends the conversation early when the answer is yes.
3. Does it need to run against realistic cluster dependencies? If the thing you are testing only means anything next to real service neighbours, real ingress, and real data shapes, then the environment has to live in the cluster. That is a placement constraint, not an isolation one, and it selects a different tool than either of the first two questions.
4. How many parallel copies, and how fast must one start? One or two at a time on the machine in front of you is a completely different problem from tens created on demand and thrown away. This is where cold start stops being a comfort issue and becomes the dominant cost, because agent tasks are often short enough that setup dominates the work.
5. Is the constraint about where code executes, or about who operates it? The last question separates two things that get conflated. "Source code must never land on an endpoint" is a network-boundary requirement. "We must be able to leave, or run this air-gapped" is an exit requirement. Both point at a full CDE, but they point at different deployment models of one.
Walk the Tree
Every option is a button, so this works entirely from the keyboard. The same tree is written out in full in the next section if you would rather read it.
The Same Tree, Written Out in Full
Work down the questions and stop at the first one that decides it. Question one is special: it does not select an answer so much as set a floor under every answer that follows.
Question 1: Is the code trusted?
Answer yes only if a person wrote it or a person reviewed it. Answer no if a model generated it and nobody has read it, if it arrived from outside your organization, or if the environment will act on text it fetched at runtime.
- Trusted: continue to question 2 and take whatever it gives you.
- Untrusted: continue to question 2, but a directory and a shared-kernel container are both off the table from here. A worktree gives no process, filesystem, or network isolation and no resource limits, so the blast radius is the whole machine. A container narrows that to the shared host kernel, which is a real improvement and still a shared kernel. For unreviewed generated code the answer is a boundary with its own kernel: a microVM, or a Kubernetes sandbox pinned to a VM-grade runtime class.
Question 2: Does it need its own kernel, nested virtualization, or a non-Linux OS?
- Yes: a microVM, or a full VM if the target is Windows or macOS or the workload needs complete OS customization. Note the prerequisite this creates: microVMs need KVM, so the hosts must be bare metal or nested-virtualization-enabled instances. Check for the device node before you design around it.
- No: go to question 3.
Question 3: Does it need realistic cluster dependencies?
- Yes: a Kubernetes sandbox, or the request-level sandbox environment pattern if you only need one or two services swapped against a shared baseline. Be exact about what the Sandbox resource gives you: the isolation comes from the runtime class on the pod template, not from the resource kind. A Sandbox with no runtime class is a pod sharing the node's kernel, with better ergonomics.
- No: go to question 4.
Question 4: How many parallel copies, and how fast must one start?
- One or two, on the machine in front of me, right now: a git worktree. It is the cheapest tier available and for two or three agents against a repository you already trust it is the correct amount of machinery. Budget for the parts that are not shared: dependency directories, build caches, and gitignored config all start empty, and every worktree wants the same ports.
- A handful, and reproducible on any machine: a devcontainer. The value here is the declaration, not the sandbox: one definition that instantiates identically on a laptop and on remote infrastructure is what makes a hybrid setup coherent instead of merely inconsistent.
- Tens or more, created on demand and thrown away: go to question 5. One machine stops being the unit at this point, and warm capacity becomes a budget line rather than a configuration detail.
Question 5: Network boundary, or exit?
- Where code executes: a full cloud development environment. When the working copy never lands on a laptop disk, a lost device exposes a session rather than a repository, network policy applies to the workspace, and access is revoked in one place. It does not stop a determined insider from copying source, and claiming otherwise oversells it.
- Who operates it: a self-hosted CDE, where you run the control plane and the compute. This buys an exit rather than a stronger boundary, and it costs you a server, a database, an ingress, and an upgrade cadence that somebody has to own.
- Neither, we just need capacity: a Kubernetes sandbox on infrastructure you already run. You have a scheduling problem, not a governance one, and buying a platform to solve it is the expensive way round.
The Five Boundaries Side by Side
Treat the ordering as the durable claim rather than the numbers. Start times depend heavily on image size, storage backend, and whether a warm pool sits in front of the tier.
| Boundary | Isolation strength | Start time shape | Operational cost | When it is overkill |
|---|---|---|---|---|
| Git worktree | None. A directory boundary only. Same user, same kernel, same credentials, same network. Blast radius is the whole developer machine. | Seconds, then however long a dependency install takes. On a large monorepo it is the difference between minutes and seconds per agent versus cloning again. | One checkout of disk. No platform to operate. The hidden costs are forgotten worktrees eating disk and port collisions between dev servers. | Never for trusted work at low concurrency - this is the floor. It is not overkill, it is under-kill the moment the code stops being reviewed. |
| Devcontainer | Namespaces and cgroups. Real process, filesystem, and resource boundaries, on a kernel shared with the host and every sibling container. | Seconds from a warm image; minutes on a cold build. Layer ordering and base image size dominate. | One file to maintain, plus image builds and a registry. The definition is portable across editors and CDE platforms, which is most of its value. | A solo project on one machine with a fast native toolchain and no second contributor. You are paying build time to solve drift you do not have. |
| Kubernetes sandbox | Entirely a function of the runtime class. Plain runc gives you the node's shared kernel; gVisor gives a syscall boundary; Kata gives a guest kernel per pod and needs KVM-capable nodes. | Seconds, or near-instant from a warm pool. Cold start is the defining performance problem here, because agent tasks are often short enough that setup dominates. | You need a cluster and someone who runs it. Warm capacity bills continuously whether or not anything claims it, so pool depth is a direct budget decision. | Any team not already operating Kubernetes. Adopting a cluster to get an isolation primitive is the most expensive route to it. |
| MicroVM | Its own guest kernel behind a hardware virtualization boundary. The strongest option here short of a full VM, and the one the untrusted-code answer points at. | Firecracker's specification commits to 125 ms or less from the InstanceStart call to guest init, with 5 MiB or less of VMM memory overhead at 1 vCPU and 128 MiB. Your workspace start time also includes image, clone, and install. | Requires KVM, so bare-metal or nested-virtualization-enabled hosts. Guest images and snapshot management become your problem. | Single-tenant work on reviewed code inside one organization. If a human reads everything before it runs, you are paying for a hypervisor to guard against yourself. |
| Full CDE | Whatever its templates provision - which is the point people miss. A CDE is an operating model, not an isolation primitive. It gives you a network boundary, an identity boundary, and an audit record, and it delegates the workspace boundary to one of the four tiers above. | Seconds from a prebuild, minutes from cold. Auto-stop policy matters more to the felt experience than raw provisioning speed does. | The largest by far, and the least measured. Self-hosting means a control plane, a database, an ingress, a template library, and an upgrade cadence with an owner. | A small co-located team on one stack with fast builds, paid-for machines, no compliance driver, and no agent fleet. You are buying an operational burden and a bill. |
What This Tool Deliberately Does Not Do
It does not recommend a vendor
Every outcome is a boundary type, not a product. Which vendor implements it is a separate question with a separate set of trade-offs, and at least four names that a 2024 shortlist would have included changed position during 2026. Start from the boundary, then shop.
It does not price anything
No break-even seat count appears here because none is published anywhere we could verify, and the operating cost of a self-hosted control plane in engineer-days is not measured by anyone. Anyone quoting you a break-even figure is quoting a model.
It does not stack
A single outcome is a simplification. Real setups combine tiers: worktrees inside a devcontainer for a human's parallel branches, microVM-backed sandboxes for the agent fleet, a CDE governing both. The tree gives you the boundary the hardest constraint demands, not the only one you will run.
The boundary is necessary, not sufficient
Picking the right tier does not finish the job. Network policy, egress allowlists, wall-clock limits enforced from outside the guest, and observability into what ran are separate decisions, and none of them come free with the runtime you chose. Getting the tier right and leaving the environment with unrestricted outbound access and a long-lived credential in it is a common and expensive mistake. See AI agent security and agent egress control for the controls that sit alongside the boundary.
Related Reading
Every outcome in the tree, in full
Git Worktrees
The cheapest tier, what it does not isolate, and the four signals that you have outgrown it
DevContainers
The portable definition, its features model, and which platforms support it fully
Kubernetes Agent Sandbox
The Sandbox CRD, warm pools, and why the runtime class is the decision that matters
MicroVM Isolation
Firecracker, Cloud Hypervisor, Kata and gVisor, and the KVM prerequisite behind all of them
Sandbox Environments
Request-level isolation against a shared baseline, and when a full environment copy is the better answer
What Is a CDE?
The operating model that wraps whichever boundary you picked, and what it actually governs
Local vs Cloud Development
The prior question: whether any of this needs to leave the machine in front of you
State of CDEs 2026
What the surveys agree on, where they contradict each other, and what nobody has measured
Sources and Citations
Publisher, year, and link for every figure used on this site