Sysbox: a runc replacement that lets containers run systemd, Docker and Kubernetes

The problem Sysbox targets: containers that need to behave like VMs

OCI containers share the host kernel. User identity and namespace isolation depend on the runtime and configuration. Running systemd, a nested Docker daemon or Kubernetes can require additional configuration or privileges with conventional container setups. The usual workarounds are privileged containers, mounting the host Docker socket, or building special rootless images with tricky entrypoints. Each of those widens the attack surface or adds image maintenance.

Sysbox is aimed at that gap. The README describes it as a specialized runc that improves container isolation and enables containers to run the same workloads as VMs. Concretely, the target users are platform and CI engineers who want Docker-in-Docker or Kubernetes-in-Docker without privileged containers, developers who want a disposable VM-like environment for testing, and teams running legacy applications that assume a full init system. The README also frames it as a way to partition bare-metal hosts or cloud instances into isolated compute environments without nested virtualization.

How sysbox-runc, sysbox-fs, sysbox-mgr and sysbox-ipc divide the work

Sysbox is not a single binary. The README identifies three main components: sysbox-runc (the runtime invoked by container managers), sysbox-fs (which virtualizes portions of procfs and sysfs), and sysbox-mgr (a manager process). The repository also includes sysbox-ipc for communication between components. The Makefile exposes per-component build and test targets such as sysbox-runc, sysbox-fs, sysbox-mgr and sysbox-ipc, which confirms they are built separately.

The data flow is the standard OCI one, with Sysbox inserted at the runtime step. Docker or Kubernetes calls the runtime named sysbox-runc instead of the default runc. Sysbox then sets up the container's namespaces, applies a Linux user namespace so container root maps to an unprivileged host identity; this reduces exposure but does not eliminate kernel or configuration vulnerabilities, and has sysbox-fs intercept reads and writes on parts of procfs and sysfs so the container sees a plausible system view rather than the host's. The README lists the resulting properties plainly: user-namespace on all containers, virtualized procfs and sysfs, host information hidden inside the container, and the container's initial mounts locked.

The project lists systemd, Docker, Kubernetes, K3s and buildx as supported system workloads without special rootless variants. Compatibility still depends on versions, image and host configuration, so test the intended workload. That last point is the design bet: instead of asking each piece of software to ship a rootless mode, Sysbox makes the container present the interfaces those tools already expect.

Installing Sysbox and running a first container with --runtime=sysbox-runc

The README points to an Installation section and states that Sysbox installs on Linux hosts, whether bare metal, VM, on-prem or cloud, and that it works on major IaaS and Kubernetes services. The repository ships sysbox-pkgr, which is where the packaging lives, so the practical route is the packaged install rather than a source build. Check the Installation section of the README for the current command and supported distributions before running anything.

Once installed, the runtime is selected per container. The README gives exactly this example:

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

What you should see is an ordinary interactive container, except that it is launched through sysbox-runc. Inside it, root maps to an unprivileged user on the host, and procfs and sysfs are virtualized. Starting systemd or an inner Docker daemon additionally requires a suitable image, configuration and supported host; the placeholder `any_image` is not itself a tested system image.

For Kubernetes, the repository includes a sysbox-k8s-manifests directory, which is where the RuntimeClass manifest for pointing pods at sysbox-runc lives. The README notes that Sysbox can coexist with other runtimes on the same host, so you choose per container or per pod which runtime to use rather than replacing the default globally.

Where Sysbox is the wrong tool

The README is direct about the central limitation: Sysbox does not use VMs, and it states that this does not provide the level of isolation that VM-based runtimes do. If your threat model assumes the workload may be actively hostile and you need a hardware boundary, a shared-kernel runtime is the wrong layer no matter how many namespaces it configures. Kata or KubeVirt exist for that case.

The isolation Sysbox does provide depends on Linux user namespaces being available and usable on the host. That makes it a Linux-only proposition; the README scopes installation to Linux hosts. It also means the runtime is not something you drop into an arbitrary container or an unprivileged CI runner that cannot install host-level components, because a container runtime has to be registered with the host's container manager.

There is a support boundary too. Sysbox was developed by Nestybox, which Docker acquired in May 2022, and Docker is the main sponsor. The README states that Sysbox is a community open-source project and is not officially supported by Docker, so Docker subscriptions do not include Sysbox support. Support is best effort through the GitHub repository or the Sysbox Slack workspace. If you need a vendor SLA, that is a reason to look elsewhere.

Sysbox compared with runc, Kata and KubeVirt

Against the default OCI runc, the difference is what the container is allowed to do. Plain runc gives you a process tree in namespaces; a container that wants to mount filesystems, manage cgroups or run an init system typically needs extra privileges, and the mapping of container root depends on the user namespace and runtime configuration. Sysbox applies the user namespace by default and virtualizes procfs and sysfs, which is what lets systemd and an inner Docker daemon run unmodified.

Against Kata Containers and KubeVirt, the difference is the mechanism rather than the goal. Both of those use VMs to isolate the workload, which the README notes gives stronger isolation but brings nested virtualization into play, something it describes as harder in cloud environments. Sysbox stays on the host kernel and therefore avoids nested virtualization, at the cost of the weaker boundary it acknowledges. The README's own framing is that Sysbox is easier to use in cloud environments while Kata and KubeVirt isolate more strongly.

Against rootless Docker or rootless Kubernetes setups, the difference is who does the work. Rootless configurations run the daemon and containers without host-root privileges, with compatibility and configuration tradeoffs that depend on the software. Sysbox instead changes the container's environment so the standard, unmodified software runs, which is a meaningful operational difference when you have images you do not control.

Maintenance, packaging and licence

Check the current release notes and supported host matrix before upgrading. The version string is read from a VERSION file at the repository root, and the Makefile marks the build as Community Edition (CE) with the package name sysbox-ce. That means upgrades are tied to the packaged artifact for your distribution, and a Makefile default does not establish which platforms receive the most testing.

Sysbox is licensed under the Apache License, Version 2.0, and the README points to the LICENSE file. Apache-2.0 is a permissive licence, but this is not legal advice: if you redistribute Sysbox or bundle it into a product, read LICENSE and OSS_DISCLOSURES.md in the repository yourself, and note that the README distinguishes the community project from Docker's commercial offerings.

The upgrade cost is mostly operational. Because Sysbox installs host-level components and registers a runtime, upgrading it touches the host's container stack rather than a single application. The README lists an Uninstallation section, so removal is documented, but the README does not document rollback to a previous version.

What Sysbox does not tell you about performance

The README has a Performance section, and it makes a density claim: partitioning bare-metal hosts into isolated compute environments with twice the density of VMs at the same performance. That is a project claim, not an independent measurement, and the README does not break down which workloads it covers or how the comparison was run. Treat it as a design goal rather than a number you can plan capacity around.

The more useful thing to reason about is where overhead would come from. sysbox-fs sits in the path of procfs and sysfs accesses, which is the component most likely to show up in a profile for workloads that read system information heavily. The README does not publish latency figures for that path. If your workload is sensitive to syscall or filesystem-interception overhead, measure it on your own kernel before committing, because nothing in the repository substitutes for that.

Editorial conclusion

Adopt Sysbox when you need Docker-in-Docker, Kubernetes-in-Docker or systemd inside a container without privileged mode or host socket mounts, and when your hosts are Linux and your kernel exposes the user-namespace features it relies on. Skip it if you need VM-grade isolation against hostile tenants, or if you cannot run its installer with host root. Before rolling it out, verify that the sysbox-runc runtime is registered with your container manager and that a test container starts under it on the exact kernel and distro you plan to use.

Frequently asked questions

Official sources

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