firecracker-containerd vs gVisor

firecracker-containerd lets containerd manage containers as Firecracker microVMs, adding isolation through the KVM hypervisor. Potential uses include sandboxing untrusted third-party containers and bin-packing different workloads on multi-tenant hosts. It uses OCI image format where possible. The project includes a control plugin and API, an out-of-process shim runtime, an agent inside the microVM, and a root filesystem image builder. That agent invokes runC through containerd-shim-runc-v1 to create Linux containers inside the microVM. Networking supports pre-created tap devices and tap devices created by CNI plugins such as bridge, ptp, host-local, firewall, and tc-redirect-tap. The software is free under Apache 2.0. Hosts require Linux 4.14 or later, Intel x86_64, and KVM; AMD and Arm are not supported. Building requires git, gcc, Docker CE, and Go 1.23 or later. The guide describes the project as very early, and multi-tenant use is at the user’s own risk.

gVisor is a free, open-source Linux-compatible sandbox and application kernel for running containers while isolating the host from untrusted code. It is intended for workloads such as user-uploaded, LLM-generated, and third-party code. Instead of passing sandboxed applications’ system calls directly to the host, its Sentry handles them; a Gofer process mediates filesystem access. The project describes a least-privilege design with a restrictive system call filter. It documents use with Docker, Kubernetes, containerd, and OCI runtimes, including Kubernetes configurations using GKE Sandbox, Minikube, or containerd with the gVisor shim. gVisor can stream application trace points to an external threat detection engine such as Falco, and can checkpoint and restore containers. Most CUDA applications can run unmodified in the sandbox with selected NVIDIA driver versions, but GPU support is restricted to certain models, drivers, capabilities, device files, ioctl calls, and platforms. Installation requires Linux 5.6 or later on x86_64 or ARM64. Compatibility is best-effort, and some applications may not work because not every system call, /proc file, or /sys file is implemented. Hardware side-channel protection is generally not provided.