Convert Figma logo to code with AI

nestybox logosysbox

An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.

2,763
151
2,763
145
View on GitHub

Top Related Projects

opencontainers's avatar

runc

11,728

CLI tool for spawning and running containers according to the OCI specification

containerd's avatar

containerd

17,086

An open and reliable container runtime

moby's avatar

moby

68,613

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

kata-containers's avatar

kata-containers

5,451

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/

google's avatar

gvisor

15,712

Application Kernel for Containers

k3s-io's avatar

k3s

27,843

Lightweight Kubernetes

Quick Overview

Sysbox is an open-source container runtime that enhances Docker and Kubernetes, allowing users to run containers with increased isolation and functionality. It enables running Docker and Kubernetes inside containers securely, making it ideal for CI/CD pipelines, testing, and development environments.

Pros

  • Improved container isolation and security
  • Ability to run Docker and Kubernetes inside containers
  • Seamless integration with existing Docker and Kubernetes workflows
  • Enhanced functionality for system-level containers

Cons

  • Requires additional setup and configuration compared to standard Docker
  • May have a slight performance overhead due to increased isolation
  • Limited compatibility with some container orchestration platforms
  • Relatively new project, still evolving and gaining adoption

Getting Started

To get started with Sysbox, follow these steps:

  1. Install Sysbox on your Linux host:
wget https://downloads.nestybox.com/sysbox/releases/v0.5.0/sysbox-ce_0.5.0-0.linux_amd64.deb
sudo apt-get install ./sysbox-ce_0.5.0-0.linux_amd64.deb
  1. Create and run a system container:
docker run --runtime=sysbox-runc -it --name=syscont nestybox/ubuntu-bionic-systemd-docker
  1. Inside the container, you can now run Docker commands:
docker run -d nginx

For more detailed instructions and advanced usage, refer to the official Sysbox documentation.

Competitor Comparisons

opencontainers logo

runc

11,728

CLI tool for spawning and running containers according to the OCI specification

Pros of runc

  • Widely adopted and supported by the container ecosystem
  • Lightweight and focused on core container runtime functionality
  • Compliant with OCI (Open Container Initiative) specifications

Cons of runc

  • Limited to running containers with host OS kernel
  • Lacks advanced isolation features for system containers

Code Comparison

runc:

func (r *Runc) Create(context context.Context, id, bundle string, opts *CreateOpts) error {
    args := []string{"create", "--bundle", bundle}
    if opts != nil {
        args = append(args, opts.AdditionalArgs...)
    }
    cmd := r.command(context, append(args, id)...)
    return runOrError(cmd)
}

Sysbox:

func (r *Runc) Create(context context.Context, id, bundle string, opts *CreateOpts) error {
    args := []string{"create", "--bundle", bundle}
    if opts != nil {
        args = append(args, opts.AdditionalArgs...)
    }
    cmd := r.command(context, append(args, id)...)
    return runOrError(cmd)
}

Summary

Sysbox is designed to enhance container isolation and enable system containers, while runc focuses on being a lightweight, OCI-compliant runtime. Sysbox offers advanced features for running system containers, but runc has broader adoption and ecosystem support. The code comparison shows similarities in their basic structure, reflecting their shared lineage in container runtime implementation.

containerd logo

containerd

17,086

An open and reliable container runtime

Pros of containerd

  • Widely adopted industry standard for container runtime
  • Extensive ecosystem and tooling support
  • Designed for high performance and scalability

Cons of containerd

  • More complex setup and configuration
  • Primarily focused on container runtime, not system-level containerization

Code comparison

containerd:

func (c *Client) NewContainer(ctx context.Context, id string, opts ...NewContainerOpts) (Container, error) {
    ctx, done, err := c.withLease(ctx)
    if err != nil {
        return nil, err
    }
    defer done(ctx)

Sysbox:

func (mgr *Manager) CreateContainer(req *api.CreateContainerReq) (*api.CreateContainerResp, error) {
    if err := mgr.validateCreateContainerReq(req); err != nil {
        return nil, err
    }
    cont, err := mgr.createContainer(req)

Key differences

  • containerd is a general-purpose container runtime, while Sysbox focuses on system containers
  • Sysbox provides stronger isolation and supports running Docker inside containers
  • containerd has broader industry adoption and integration with Kubernetes
  • Sysbox offers easier setup for system-level containerization use cases

Use cases

containerd:

  • Kubernetes deployments
  • Cloud-native applications
  • Microservices architectures

Sysbox:

  • Nested containerization
  • Development environments
  • Legacy application containerization
moby logo

moby

68,613

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

Pros of Moby

  • Widely adopted and battle-tested in production environments
  • Extensive ecosystem with numerous plugins and integrations
  • Comprehensive documentation and large community support

Cons of Moby

  • Can be resource-intensive, especially for large-scale deployments
  • Potential security concerns due to shared kernel and root access

Code Comparison

Moby (Docker) container run command:

docker run -it --rm ubuntu:latest /bin/bash

Sysbox container run command:

docker run --runtime=sysbox-runc -it --rm ubuntu:latest /bin/bash

Key Differences

  • Sysbox focuses on enhanced isolation and security for containers
  • Moby (Docker) provides a more general-purpose container runtime
  • Sysbox allows running systemd, Docker, and Kubernetes inside containers
  • Moby has a larger ecosystem and broader adoption in the industry

Use Cases

  • Sysbox: Ideal for scenarios requiring stronger isolation or nested containerization
  • Moby: Suitable for most general container workloads and microservices architectures

Both projects aim to improve container technology, with Sysbox emphasizing security and isolation, while Moby (Docker) offers a more versatile and widely-adopted solution for containerization needs.

kata-containers logo

kata-containers

5,451

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/

Pros of kata-containers

  • Provides stronger isolation by using lightweight VMs, offering enhanced security
  • Supports multiple architectures and hypervisors, increasing flexibility
  • Integrates well with Kubernetes and OpenStack, enhancing cloud-native compatibility

Cons of kata-containers

  • Higher resource overhead compared to traditional containers
  • Potentially slower startup times due to VM initialization
  • More complex setup and management than standard container runtimes

Code comparison

kata-containers:

devices:
  - path: /dev/vfio/vfio
    type: c
    major: 10
    minor: 196
    file_mode: 0600
    uid: 0

sysbox:

mounts:
  - type: bind
    source: /var/lib/sysbox
    destination: /var/lib/sysbox
    options: ["rbind", "rshared"]

While both projects aim to enhance container security and isolation, they take different approaches. kata-containers uses lightweight VMs for stronger isolation, while sysbox focuses on improving the security of traditional containers through system-level enhancements. The code snippets show configuration examples for device access in kata-containers and mount options in sysbox, highlighting their different focuses on VM-based and container-based approaches, respectively.

google logo

gvisor

15,712

Application Kernel for Containers

Pros of gVisor

  • Provides stronger isolation and security by implementing its own kernel
  • Offers better compatibility with existing Docker workflows
  • Supports a wider range of Linux system calls

Cons of gVisor

  • Higher performance overhead compared to native containers
  • Limited hardware and kernel feature support
  • More complex setup and configuration process

Code Comparison

gVisor uses a custom runtime called "runsc" to intercept system calls:

func (l *Loader) switchToApp(ctx context.Context) error {
    // Switch to application.
    return l.switchToApp(ctx)
}

Sysbox uses Linux namespaces and cgroups for isolation:

int syscont_create(struct syscont_create_args *args)
{
    return syscont_create_impl(args);
}

Key Differences

  • gVisor focuses on security through a user-space kernel, while Sysbox enhances container isolation using existing Linux features
  • Sysbox aims for better performance and compatibility with standard container runtimes
  • gVisor provides stronger security guarantees but at the cost of performance and compatibility

Use Cases

  • gVisor: Ideal for running untrusted workloads or in multi-tenant environments with high security requirements
  • Sysbox: Suitable for general-purpose containerization, nested containers, and scenarios requiring better performance
k3s-io logo

k3s

27,843

Lightweight Kubernetes

Pros of k3s

  • Lightweight Kubernetes distribution, ideal for edge computing and IoT devices
  • Easy to install and manage, with a single binary under 100MB
  • Includes built-in storage and load balancing solutions

Cons of k3s

  • Limited to container workloads, not suitable for system-level isolation
  • May require additional configuration for advanced Kubernetes features
  • Less flexibility in terms of runtime environment customization

Code Comparison

k3s installation:

curl -sfL https://get.k3s.io | sh -

Sysbox installation:

wget https://github.com/nestybox/sysbox/releases/download/v0.5.0/sysbox-ce_0.5.0-0.ubuntu-focal_amd64.deb
sudo apt-get install ./sysbox-ce_0.5.0-0.ubuntu-focal_amd64.deb

Key Differences

  • k3s focuses on providing a lightweight Kubernetes distribution, while Sysbox offers system-level container runtime
  • k3s is designed for running containerized applications, whereas Sysbox enables running system-level software in containers
  • k3s is more suitable for orchestrating microservices, while Sysbox excels at creating isolated development environments and running system software

Use Cases

  • k3s: Edge computing, IoT devices, small-scale Kubernetes deployments
  • Sysbox: Development environments, system-level software testing, enhanced container isolation

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

sysbox

GitHub license build status

Introduction

Sysbox is an open-source and free container runtime (a specialized "runc"), originally developed by Nestybox (acquired by Docker on 05/2022), that enhances containers in two key ways:

  • Improves container isolation:

    • Linux user-namespace on all containers (i.e., root user in the container has zero privileges on the host).

    • Virtualizes portions of procfs & sysfs inside the container.

    • Hides host info inside the container.

    • Locks the container's initial mounts, and more.

  • Enables containers to run same workloads as VMs:

    • With Sysbox, containers can run system-level software such as systemd, Docker, Kubernetes, K3s, buildx, legacy apps, and more seamlessly & securely.

    • This software can run inside Sysbox containers without modification and without using special versions of the software (e.g., rootless variants).

    • No privileged containers, no complex images, no tricky entrypoints, no special volume mounts, etc.

Think of it as a "container supercharger": it enables your existing container managers / orchestrators (e.g., Docker, Kubernetes, etc.) to deploy containers that have hardened isolation and can run almost any workload that runs in VMs.

Sysbox does this by making the container resemble a VM-like environment as much as possible, using advanced OS virtualization techniques.

Unlike alternative runtimes such as Kata and KubeVirt, it does not use VMs. This makes it easier to use (particularly in cloud environments by avoiding nested virtualization), although it does not provide the level of isolation that VM-based runtimes do. See here for a comparison.

There is no need to learn new tools or modify your existing container images or workflows to take advantage of Sysbox. Simply install it and point your container manager / orchestrator to it to deploy enhanced containers.

Sysbox can live side-by-side with other container runtimes on the same host (e.g., the default OCI runc, Kata, etc.) You can easily choose which containers or pods to run with each, depending on your needs.

Demo Videos

Contents

License

Sysbox is free and open-source, licensed under the Apache License, Version 2.0. See the LICENSE file for details.

Relationship to Nestybox & Docker

Sysbox was originally developed by Nestybox. As Nestybox is now part of Docker, Docker is the main sponsor of the Sysbox project.

Having said this, Sysbox is a community open-source project and it's not officially supported by Docker (i.e., Docker subscriptions do not include Sysbox support). Support is provided on a best effort basis via this Github repo or via the Sysbox Slack Workspace.

We encourage participation from the community to help evolve and improve Sysbox, with the goal of increasing the use cases and benefits it enables. External maintainers and contributors are welcomed.

Motivation

Sysbox solves problems such as:

  • Enhancing the isolation of containerized microservices (root in the container maps to an unprivileged user on the host).

  • Enabling a highly capable root user inside the container without compromising host security.

  • Securing CI/CD pipelines by enabling Docker-in-Docker (DinD) or Kubernetes-in-Docker (KinD) without insecure privileged containers or host Docker socket mounts.

  • Enabling the use of containers as "VM-like" environments for development, local testing, learning, etc., with strong isolation and the ability to run systemd, Docker, IDEs, and more inside the container.

  • Running legacy apps inside containers (instead of less efficient VMs).

  • Replacing VMs with an easier, faster, more efficient, and more portable container-based alternative, one that can be deployed across cloud environments easily.

  • Partitioning bare-metal hosts into multiple isolated compute environments with 2X the density of VMs (i.e., deploy twice as many VM-like containers as VMs on the same hardware at the same performance).

  • Partitioning cloud instances (e.g., EC2, GCP, etc.) into multiple isolated compute environments without resorting to expensive nested virtualization.

How it Works

sysbox

Sysbox installs easily on Linux hosts (bare-metal, VM, on-prem, cloud, etc.). It works on all mayor cloud-based IaaS and Kubernetes services (e.g., EC2, GCP, GKE, EKS, AKS, Rancher, etc.)

Once installed, Sysbox works under the covers: you use Docker, Kubernetes, etc. to deploy containers with it.

For example, this simple Docker command creates a container with Sysbox:

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

You get a well isolated container capable of seamlessly running microservices as well as system-level software that normally that runs on VMs (e.g., systemd, Docker, Kubernetes, etc).

More on how to use Sysbox here.

Comparison to Related Technologies

sysbox

As shown, Sysbox enables unprivileged containers to run system-level workloads such as systemd, Docker, Kubernetes, etc., seamlessly, while giving you a balanced approach between container isolation, performance, efficiency, and portability.

And it does this with minimal configuration changes to your existing infra: just install Sysbox and configure your container manager/orchestrator to launch containers with it, using the image of your choice.

Note that while Sysbox hardens the isolation of standard containers and voids the need for insecure privileged containers in many scenarios, it does not (yet) provide the same level of isolation as VM-based alternatives or user-space OSes like gVisor. Therefore, for scenarios where the highest level of isolation is required, alternatives such as KubeVirt may be preferable (at the expense of lower performance and efficiency and higher complexity and cost).

See this blog post for more.

Audience

The Sysbox project is intended for anyone looking to experiment, invent, learn, and build systems using system containers. It's cutting-edge OS virtualization, and contributions are welcomed.

Sysbox Enterprise Edition [DEPRECATED]

Prior to the acquisition by Docker on 05/2022, Nestybox offered Sysbox Enterprise as an enhanced version of Sysbox (e.g., more security, more workloads, and official support).

After the acquisition however, Sysbox Enterprise is no longer offered as a standalone product but has instead been incorporated into Docker Desktop (see Docker Hardened Desktop).

NOTE: As Sysbox Enterprise is no longer offered as a standalone product, Docker plans to make some Sysbox Enterprise features available in Sysbox Community Edition. The features are TBD and your feedback on this is welcome.

Sysbox Features

The table below summarizes the key features of the Sysbox container runtime.

It also provides a comparison between the Sysbox Community Edition (i.e., this repo) and the previously available Sysbox Enterprise Edition (now deprecated).

sysbox

More on the Sysbox features here.

If you have questions, you can reach us here.

System Containers

We call the containers deployed by Sysbox system containers, to highlight the fact that they can run not just micro-services (as regular containers do), but also system software such as Docker, Kubernetes, Systemd, inner containers, etc.

More on system containers here.

Installation

Host Requirements

The Sysbox host must meet the following requirements:

  • It must be running one of the supported Linux distros and be a machine with a supported architecture (e.g., amd64, arm64).

  • We recommend a minimum of 4 CPUs (e.g., 2 cores with 2 hyperthreads) and 4GB of RAM. Though this is not a hard requirement, smaller configurations may slow down Sysbox.

Installing Sysbox

The method of installation depends on the environment where Sysbox will be installed:

Using Sysbox

Once Sysbox is installed, you create a container using your container manager or orchestrator (e.g., Docker or Kubernetes) and an image of your choice.

Docker command example:

$ docker run --runtime=sysbox-runc --rm -it --hostname my_cont registry.nestybox.com/nestybox/ubuntu-bionic-systemd-docker
root@my_cont:/#

Kubernetes pod spec example:

apiVersion: v1
kind: Pod
metadata:
  name: ubu-bio-systemd-docker
  annotations:
    io.kubernetes.cri-o.userns-mode: "auto:size=65536"
spec:
  runtimeClassName: sysbox-runc
  containers:
  - name: ubu-bio-systemd-docker
    image: registry.nestybox.com/nestybox/ubuntu-bionic-systemd-docker
    command: ["/sbin/init"]
  restartPolicy: Never

You can choose whatever container image you want, Sysbox places no requirements on the image.

Nestybox makes several reference images available in its Dockerhub and GitHub Container Registry repos. These are images that typically include systemd, Docker, Kubernetes, and more inside the containers. The Dockerfiles are here. Feel free to use and modify per your needs.

Documentation

We strive to provide good documentation; it's a key component of the Sysbox project.

We have several documents to help you get started and get the best out of Sysbox.

Performance

Sysbox is fast and efficient, as described in this Nestybox blog post.

The containers created by Sysbox have similar performance to those created by the OCI runc (the default runtime for Docker and Kubernetes).

Even containers deployed inside the system containers have excellent performance, thought there is a slight overhead for network IO (as expected since packets emitted by inner containers go through an additional network interface / bridge inside the system container).

Now, if you use Sysbox to deploy system containers that replace VMs, then the performance and efficiency gains are significant: you can deploy 2X as many system containers as VMs on the same server and get the same performance, and do this with a fraction of the memory and storage consumption. The blog post referenced above has more on this.

Under the Covers

Sysbox was forked from the excellent OCI runc in early 2019 and it stands on the shoulders of the work done by the OCI runc developers.

Having said this, Sysbox adds significant functionality on top. It's written in Go, and it is currently composed of three components: sysbox-runc, sysbox-fs, and sysbox-mgr.

Sysbox uses many OS-virtualization features of the Linux kernel and complements these with OS-virtualization techniques implemented in user-space. These include using all Linux namespaces (in particular the user-namespace), partial virtualization of procfs and sysfs, selective syscall trapping, and more.

More on Sysbox's design can be found in the Sysbox user guide.

Sysbox does not use hardware virtualization

Though the containers generated by Sysbox resemble virtual machines in some ways (e.g., you can run as root, run multiple services, and deploy Docker and K8s inside), Sysbox does not use hardware virtualization.

Sysbox is a pure OS-virtualization technology meant to create containers that can run applications as well as system-level software, easily and securely.

This makes the containers created by Sysbox fast, efficient, and portable (i.e., they aren't tied to a hypervisor).

Isolation wise, it's fair to say that Sysbox containers provide stronger isolation than regular Docker containers (by virtue of using the Linux user-namespace and light-weight OS shim), but weaker isolation than VMs (by sharing the Linux kernel among containers).

Contributing

We welcome contributions to Sysbox, whether they are small documentation changes, bug fixes, or feature additions. Please see the contribution guidelines and developer's guide for more info.

Security

See the User Guide's Security Chapter for info on how Sysbox secures containers.

If you find bugs or issues that may expose a Sysbox vulnerability, please report these by sending an email to security@nestybox.com. Please do not open security issues in this repo. Thanks!

In addition, a few vulnerabilities have recently been found in the Linux kernel that in some cases reduce or negate the enhanced isolation provided by Sysbox containers. Fortunately they are all fixed in recent Linux kernels. See the Sysbox User Guide's Vulnerabilities & CVEs chapter for more info, and reach out on the Sysbox Slack channel for further questions.

Troubleshooting & Support

Support is currently offered on a best-effort basis.

If you have a question or comment, we love to hear it. You can reach us at our slack channel or file an issue on this GitHub repo.

If you spot a problem with Sysbox, please search the existing issues as they may describe the problem and provide a work-around.

Check also the Troubleshooting document.

Uninstallation

Prior to uninstalling Sysbox, make sure all containers deployed with it are stopped and removed.

The method of uninstallation depends on the method used to install Sysbox:

Roadmap

The following is a list of features in the Sysbox roadmap.

We list these here so that our users can get a better idea of where we are going and can give us feedback on which of these they like best (or least).

Here is a short list; the Sysbox issue tracker has many more.

  • Support for more Linux distros.

  • More improvements to procfs and sysfs virtualization.

  • Continued improvements to container isolation.

  • Exposing host devices inside system containers with proper permissions.

Contact

Slack: Sysbox Slack Workspace

Email: contact@nestybox.com

We are available from Monday-Friday, 9am-5pm Pacific Time.

Thank You

We thank you very much for using and/or contributing to Sysbox. We hope you find it interesting and that it helps you use containers in new and more powerful ways.