Sysbox: Running Docker-in-Docker and Kubernetes Inside Containers Without Privileged Mode

The Problem: Privileged Containers and the Isolation Gap

Running Docker inside a container, or running Kubernetes inside a container, is a common requirement for CI/CD pipelines and local development environments. The standard solution is a privileged container, which removes nearly all Linux security boundaries between the container and the host. A process escaping a privileged container has root on the host.

An alternative is mounting the host Docker socket into the container, which is functionally equivalent from a security standpoint: any process inside the container can issue Docker commands with host-level access.

Sysbox addresses both problems by acting as a specialised container runtime. It installs alongside the standard OCI runc and other runtimes on the same host. When a container is started with --runtime=sysbox-runc, Sysbox applies a Linux user namespace so that root inside the container maps to an unprivileged user on the host. It also virtualises portions of procfs and sysfs inside the container, hides host information, and locks initial mounts. The result is a container that can run systemd, a full Docker daemon, or a Kubernetes node as though it were a VM, while the host sees it as an unprivileged process.

How Sysbox Works: User Namespaces and Kernel Virtualisation

The core mechanism is the Linux user namespace. Sysbox applies it to every container it starts. Root inside the container (UID 0) maps to a non-root UID on the host. The mapping is automatic; no special container image or Dockerfile instruction is required.

Beyond the user namespace, Sysbox virtualises selected kernel interfaces that system-level software typically reads or writes. Procfs entries that expose host configuration, sysfs entries that control networking stack parameters, and cgroup hierarchies are presented to the container in an isolated view. This is what allows software like systemd (which checks and writes to these interfaces at startup) to run inside the container without modification and without the container having any real influence on those parameters on the host.

The Docker README example shows the minimal change required to use Sysbox:

docker run --runtime=sysbox-runc -it any_image

No custom image, no special entrypoint, no volume mounts for /var/run/docker.sock. The container manager simply delegates to sysbox-runc instead of runc.

The runtime consists of three components referenced in the Makefile: sysbox-runc (the OCI runtime itself), sysbox-fs (the filesystem virtualisation daemon), and sysbox-mgr (the manager that coordinates between them). All three must be running for Sysbox to operate.

Installation and First Use

Sysbox installs on Linux hosts. The README states it works on bare metal, VMs, on-premises environments, and major cloud platforms including EC2, GCP, GKE, EKS, AKS, and Rancher.

Installation packages are not reproduced in the README inline; the documentation directory contains detailed instructions. The Makefile lists the build targets for building from source:

make sysbox

This builds sysbox-runc, sysbox-fs, and sysbox-mgr. An install target is also provided:

make install

After installation, the runtime registers with Docker (or another OCI-compatible manager) and becomes available as a selectable runtime.

For Kubernetes, Sysbox can be deployed as a runtime class, and sysbox-k8s-manifests/ in the repository contains the relevant YAML manifests. Pods in that runtime class gain the same isolation and system-software capabilities as Docker containers started with --runtime=sysbox-runc.

Sysbox vs. runc, Kata Containers, and containerd

The standard OCI runc runs containers with the host user namespace shared. Root in the container is root on the host. Sysbox replaces runc with a drop-in that adds user-namespace isolation and procfs/sysfs virtualisation. The trade-off is a small amount of additional overhead for the virtualisation layer; the README notes performance is measured relative to runc, not to VMs.

Kata Containers runs each container inside a lightweight VM using hardware virtualisation. The isolation boundary is the hypervisor, which is stronger than any Linux namespace-based approach. The cost is that Kata requires a hypervisor-capable host (nested virtualisation on cloud VMs is possible but expensive), and it does not work in environments where hardware virtualisation is unavailable. Sysbox avoids this dependency and is easier to deploy in cloud environments, but the README explicitly acknowledges it does not match Kata's isolation level.

KubeVirt takes a different approach: it runs full virtual machines as Kubernetes workloads. It is suitable for cases where the workload itself must be a VM, not a container. Sysbox targets the opposite case: containers that need to behave like VMs without actually being VMs.

containerd is a container runtime daemon that calls runc (or an alternative) under the covers. Sysbox plugs into containerd's shim interface and can be used as the runtime within a containerd-managed cluster the same way it integrates with Docker.

Limitations and Cases Where Sysbox Is the Wrong Tool

Sysbox's isolation relies on Linux namespaces and kernel virtualisation. It does not provide the same isolation guarantee as a hardware-based boundary. The README is direct about this: if the threat model requires VM-level isolation, Kata Containers or KubeVirt are the appropriate tools.

Sysbox runs on Linux only. macOS and Windows hosts running Docker through a Linux VM may be able to use it, but only within that VM.

Kernel version requirements apply. The README does not reproduce the full support matrix inline, but distributions on older kernels may not have the user namespace features Sysbox depends on. Checking kernel version and distribution compatibility against the Sysbox documentation is a necessary step before deploying it in a new environment.

Support is community-based. Nestybox was acquired by Docker in May 2022, and Docker is the project's main sponsor, but Sysbox is explicitly not covered by Docker subscriptions. Support is provided on a best-effort basis through the GitHub repository and the Sysbox Slack workspace. Production deployments that require contracted support are not available.

The enterprise edition (Sysbox Enterprise Edition, also referenced in the README) is a separate product. The community edition (Sysbox CE) in this repository is the open-source variant under Apache-2.0.

Maintenance and Licence

The last push to the repository was on 2026-09-15. The most recent release is v0.7.1, published on 2026-07-31. The previous release, v0.7.0, was published on 2026-06-02. The repository is not archived.

Sysbox is licenced under the Apache License, Version 2.0. The licence permits use, modification, and distribution, including in proprietary systems, provided the copyright and licence notices are retained. The repository includes an OSS_DISCLOSURES.md file that documents dependencies and their licences.

The project has a CONTRIBUTING.md and MAINTAINERS file. External maintainers and contributors are welcomed, per the README.

Editorial conclusion

Sysbox is worth adopting if your team runs Docker-in-Docker or Kubernetes-in-Docker for CI/CD pipelines and is currently doing so with privileged containers or host Docker socket mounts, which expose the host to container escape risks. It is also a practical choice for partitioning a bare-metal host or cloud VM into isolated, VM-like development environments without the overhead of nested virtualisation. It is the wrong choice if your security model requires the full hardware-level isolation that Kata Containers or KubeVirt provide, since Sysbox explicitly trades that level of isolation for easier deployment and better performance. Verify that your Linux kernel and distribution are in the supported matrix before installing, and note that Sysbox is not covered by Docker subscription support.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nestybox/sysbox on GitHub
4. README
5. Releases