For code you wrote or reviewed, a hardened container is usually enough. For code from strangers or other customers, add a stronger boundary: an application kernel such as gVisor, a microVM such as Firecracker, or a full virtual machine. The more hostile the code, the further the boundary should sit from your host kernel.
The four options in plain terms
Container with kernel controls. The workload runs as a host process, limited by namespaces, seccomp, capabilities and similar features. The gVisor documentation notes that in this model the attack surface is reduced, but enforcement is still done by the single Linux kernel the workload can talk to, so the workload is one system call away from the host.
Application kernel. gVisor describes itself as an application kernel, not a hypervisor or a system call filter. It runs in user space, handles the workload's system calls itself using a Go reimplementation of the Linux interface, and passes none of them straight to the host. The cost is compatibility: if a kernel feature is not reimplemented, the workload cannot use it.
MicroVM. Firecracker is an open source virtual machine monitor that uses the kernel's KVM to create lightweight virtual machines. Its project page describes only five emulated devices and a companion program called the jailer, which adds a second layer of Linux user space barriers in case the virtualization barrier is ever compromised.
Full virtual machine. The gVisor documentation calls virtual machines the gold standard of workload isolation, at a steep cost in overhead because each one boots a separate kernel and has resources allocated up front.
A comparison table
| Option | Where the boundary sits | Main trade off |
|---|---|---|
| Hardened container | Host kernel shared | Cheapest and most compatible, weakest boundary |
| Application kernel | User space reimplementation of the kernel | Smaller host exposure, some compatibility gaps |
| MicroVM | Hardware virtualization with a minimal device model | Stronger boundary, needs virtualization support on the host |
| Full VM | Hardware virtualization with a full guest kernel | Strong boundary, most overhead |
The statements about each design come from the projects' own documentation. This post does not rank them, because the right choice depends on your workload.
Questions that pick for you
- Who wrote the code? Your own team, a vendor, or an anonymous user? Strangers push you toward a stronger boundary.
- Do different customers share a host? gVisor's documentation advises running different customer workloads in different sandboxes.
- What does the workload need from the kernel? Unusual system calls, devices or kernel modules may not work under an application kernel.
- Can your hosts run virtualization? MicroVMs need hardware virtualization support. Firecracker lists 64-bit Intel, AMD and Arm CPUs with it.
- How fast must it start? Overhead and startup time matter for short lived jobs.
What no sandbox covers
A sandbox limits what a compromise can reach. The workload still has whatever the sandbox grants. gVisor's own security model states that a sandbox is not a substitute for a secure architecture, and that an exploitable network service on the host stays exploitable. Keep secrets out of the sandbox, restrict its network, and treat its output as untrusted.
For deeper reads on single designs, see what gVisor does not protect against, the Firecracker security model and the container checklist.
Safeguard scans the dependencies and images you place in any of these environments, and the free scan is at gold.safeguard.sh/scan.
Quick check
Is a container ever enough for untrusted code?
For low stakes checks with no secrets and no network, it can reduce risk. For hostile code or shared hosts, add a boundary that does not rely on the host kernel alone.
Does a microVM make the workload itself safe?
No. It limits what the workload can reach on the host. The workload keeps whatever data and network access you give it.
Sources
Last reviewed: 19 October 2026.
