§1The Launch
Bastion turned up on Hacker News this week with a single, blunt promise: deploy a real virtual computer for every coding agent you run. Not a container, not a git worktree, not a tmux pane with a polite naming convention. A whole Linux machine, booted fresh, that the agent owns from the filesystem up to its own background processes. You install it with one curl line, define each environment as a schema-validated JSON template, and self-host the whole thing on any Linux box with KVM, from your laptop to an EC2 instance.
The pitch is aimed squarely at people running several agents at once: "zero runtime conflicts from other agents working in parallel." If you have ever watched two background agents fight over port 3000, or one npm install quietly stamp on another, you already know the problem it is selling against.
§2Why A VM, Not A Container
The default way to isolate a coding agent today is a container or a worktree. Both share the host kernel. That is fine until the thing inside the box is an autonomous agent with a shell, root, and a willingness to run whatever it decides is necessary. A shared kernel means a noisy agent can starve its neighbours, a global install leaks across boundaries, and a kernel-level bug is a shared blast radius rather than a contained one.
Bastion's argument is that an agent is not a process you are supervising, it is a tenant you are hosting, and tenants get machines. Each environment is a separate microVM with its own kernel, its own root filesystem, its own network namespace and its own process table. An agent can thrash, fork-bomb, rewrite its own system packages, and the only thing it harms is its own disposable computer. When you are done, you tear the VM down and the mess goes with it.
§3How It Actually Works
This is where it gets honest rather than hand-wavy. Bastion launches guests with Cloud Hypervisor, the same lightweight KVM virtual machine monitor used in serious microVM setups, not a heavyweight desktop hypervisor. The host needs /dev/kvm, x86_64, and a privileged daemon running as root; a second, unprivileged API process is what your CLI actually talks to.
Each guest boots a managed Ubuntu 24.04 kernel and initramfs over a copied base rootfs image. Networking is plumbed by hand with TAP interfaces, iptables NAT and IPv4 forwarding. The clever bit is the tunnels: your dev server binds to plain localhost inside the guest, and Bastion reaches it through a guest proxy over a Cloud Hypervisor vsock channel, so nothing has to listen on 0.0.0.0 to be previewable. The agent itself is OpenCode, installed during template preparation, snapshotted, then restarted when you spin up an environment, which is how a new agent box comes up quickly rather than reinstalling the world each time. Shell access is root SSH multiplexed over a custom bastion-ssh protocol, though you are told to treat that as an implementation detail and use the CLI.
§4The Catch
Read the docs and the boundaries are clear. It is OpenCode or nothing right now; the template schema requires an opencode agent, so this is not a drop-in for an arbitrary fleet of different agents yet. It is x86_64 and KVM only, which means no native Apple Silicon and nested virtualisation if you run it inside another VM. And critically, you host the metal. Bastion is not a managed cloud that bills per second; it is software you run, which means the idle microVMs waiting for their agents are your hardware and your cost. A microVM is lighter than a full VM and heavier than a container, and at fleet scale that middle is a line item, not a rounding error.
None of this is a knock. It is the shape of the honest version of this idea. Real isolation is not free, and Bastion is refreshingly direct about charging for it in resources rather than pretending containers were ever enough.
§5What It Means For Builders
We run a fleet of background agents here, so this lands on our own desk. This very article was drafted by one of them. And the lesson we keep relearning is that isolation has two halves, and Bastion cleanly solves one of them.
The half it solves is isolation between agents. A microVM stops agent A from wrecking agent B, from squatting its ports, from corrupting a shared dependency. That is genuinely valuable and most setups fake it.
The half it does not touch is the blast radius within a single agent. A perfectly isolated VM still holds your API key, your cloned repository and write access to whatever you handed it. An agent that goes wrong inside its own pristine box can still push bad code, leak the secret it was given, or burn your tokens. Machine-level isolation bounds what one agent can do to another; it does nothing about what one agent can do with the authority you granted it. That is a permissions question, and no hypervisor answers it.
So the right reading of Bastion is not "containers are over." It is that the unit of isolation for agents is quietly moving from the process to the machine, which fixes neighbour-on-neighbour damage and changes your cost model before it changes your security model. Buy the VM for the blast radius between agents. Then go draw the permission boundary inside each one, because that is the bill Bastion was never trying to pay.