# youki: a Rust OCI runtime you can drop into Docker or containerd

> youki implements the OCI runtime-spec in Rust and is meant to sit behind Docker, containerd or Podman where runc normally runs. The build is Linux-only, the README's benchmark is self-reported, and the interesting engineering is in how it handles namespaces and seccomp.

**youki-dev/youki** — A container runtime written in Rust

- Repository: https://github.com/youki-dev/youki
- Website: https://youki-dev.github.io/youki/
- Stars: 7,613 · Forks: 474
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/youki-dev-youki

## What youki is, and which container users it is actually for

youki is an implementation of the OCI runtime-spec written in Rust, described in its README as "similar to runc". That sentence is the whole pitch. A runtime at this layer is the last process in the chain: containerd or Docker decides what a container should look like, writes an OCI bundle, and then execs a runtime binary that performs the namespaces, cgroups, mounts and seccomp filters and hands control to the container process. youki is that binary.

The intended user is therefore not someone who runs docker run directly. It is a platform engineer who already has containerd, Docker or Podman in place and wants to swap the runtime underneath. The README's quick start shows exactly this shape, with youki passed as the runtime to docker run and to podman run with --cgroup-manager=cgroupfs. If you have no container manager and want one, youki is the wrong thing to install.

The project's stated motivation is partly technical and partly candid. The README argues Rust handles the system-call-heavy parts of a runtime better than Go, and that memory safety is a benefit C does not provide. It also lists a reason that most project READMEs would leave out: "I have fun implementing this. In fact, this may be the most important." That is worth knowing when you weigh how the roadmap gets prioritised.

## How youki executes a container: bundle in, namespaces out

The entry point is a filesystem bundle. The README's tutorial builds one by exporting a busybox image into a rootfs directory and then generating a config.json with the youki spec subcommand. That config.json is the OCI runtime configuration: the process to run, its arguments and environment, and the sandboxing features to apply. youki reads it, sets up the container according to it, and starts the process.

The lifecycle is explicit and matches the spec: create, start, delete. The README's own benchmark command chains all three against a bundle named a, which tells you the runtime does not hide the container's lifetime behind a single foreground command. The repository layout backs this up: the CLI surface lives in crates/liboci-cli, which the workspace pins at version 0.7.0, and the runtime itself is in crates/. There is a separate companion project, oci-spec-rs, that implements the OCI runtime and image spec types in Rust, so the spec structures youki parses are not hand-rolled inside the runtime crate.

Seccomp, cgroups and namespace handling are not optional extras here. The workspace depends on libseccomp and libbpf-sys, and the build instructions require libseccomp-dev or libseccomp-devel as a system package, so a seccomp filter in the config is applied through the C library rather than a pure-Rust reimplementation. The README's own info output enumerates mount, uts, ipc, user, pid, network and cgroup namespaces individually, which is the list you would check on a host before trusting it.

## Building youki on Debian, Ubuntu, Fedora or RHEL

Local builds are Linux-only, and the README is direct about that: other platforms should use the provided Vagrantfile or a GitHub Codespace. You need Rust with edition 2024 and a Linux kernel of 5.3 or newer.

On Debian, Ubuntu and related distributions, install the system dependencies first. These are the packages named in the README, and the seccomp, systemd, elf and clang entries are the ones a bare build environment will be missing.

```bash
sudo apt-get install    \
      pkg-config        \
      libsystemd-dev    \
      build-essential   \
      libelf-dev        \
      libseccomp-dev    \
      libclang-dev      \
      libssl-dev
```

On Fedora, CentOS, RHEL and related distributions the equivalent set uses dnf and different package names for the same libraries.

```bash
sudo dnf install            \
      pkg-config            \
      systemd-devel         \
      elfutils-libelf-devel \
      libseccomp-devel      \
      clang-devel           \
      openssl-devel
```

You also need just, the task runner, installed separately. Then clone and build. The justfile defines youki-dev and youki-release, and youki-release is the alias for plain just build.

```bash
git clone git@github.com:youki-dev/youki.git
cd youki
just youki-dev # or youki-release
./youki -h # you can get information about youki command
```

After the build, the binary sits at the repository root. Running ./youki -h prints the command list; the README points to this as the way to discover the CLI. There is also a just install target that copies the built binary to /usr/local/sbin/youki using install -D -m 0755, which is the step that makes it visible to a container manager looking for a runtime on the system path.

## Running a first container with youki and a busybox rootfs

The tutorial needs Docker present, because Docker is used only as an image exporter. The container you actually run is started by youki. Root permission may be needed.

Create the bundle directory and populate the rootfs by exporting a busybox image into it. The docker create plus docker export pipeline is what produces a real filesystem tree.

```bash
mkdir -p tutorial/rootfs
cd tutorial
# use docker to export busybox into the rootfs directory
docker export $(docker create busybox) | tar -C rootfs -xvf -
```

Now generate the OCI configuration. The spec subcommand writes a config.json into the current directory, containing metadata and specs such as the process to run, environment variables to inject and sandboxing features to use.

```bash
../youki spec  # will generate a spec file named config.json
```

Edit that config.json so the process field runs something observable. The README changes the args array to sleep 30, which is the smallest change that proves the container starts and stays alive long enough for you to inspect it.

```json
  "process": {
    ...
    "args": [
      "sleep", "30"
    ],

  ...
  }
```

With the bundle in place, the lifecycle commands are create, start and delete, as used in the README's benchmark. If you would rather not build at all, the README also offers a preconfigured GitHub Codespace where just build is followed by docker run --runtime youki hello-world, and a Podman variant that passes --runtime /workspaces/youki/youki with --cgroup-manager=cgroupfs.

## The benchmark table in the README is self-reported and stale

The README includes a hyperfine comparison of container creation to deletion across youki, runc and crun. Read the version column before you read the numbers. The youki row is version 0.3.3, while the most recent release listed for the repository is v0.7.0, published on 2026-07-25. The runc row is 1.1.7 and the crun row is 1.15. Those are not the versions you would install today, and nothing in the README says the table has been re-run since.

The measurements themselves come from a single machine, an Ubuntu 22.04.4 LTS host with 16 cores and 63870 MB of total memory, with the kernel page cache dropped before each run via sync and drop_caches. That is a reasonable methodology for a microbenchmark and a poor basis for a capacity plan. The README's own framing is conditional: youki "has the potential to be faster and use less memory than runc". Potential, not a guarantee, and the table also shows crun ahead of youki on the same measurement.

So treat the numbers as evidence that the authors cared about startup cost, not as a reason to switch. If startup latency is your deciding factor, you need to reproduce the hyperfine command on your own kernel and filesystem. The command is printed in the README, including the warmup and run counts, so it is reproducible in principle.

## Where youki is the wrong tool, and what runc does differently

The obvious alternative is runc, the reference implementation of the same spec and the runtime Docker and containerd ship by default. The difference is the implementation language and what follows from it. runc is Go; youki is Rust. The README's argument is that a runtime makes heavy use of namespaces(7) and fork(2), which need special handling in Go, and that Rust gives memory safety without C's risks. That is a claim about the code you are trusting with host privileges, and it is the main reason to pick youki over runc. It is not a claim that youki is more complete.

crun is the other comparison the README itself makes, and it is written in C. It appears in the benchmark table as the fastest of the three. If raw container startup is your only criterion, the README's own data points at crun rather than youki, and you should say so rather than picking youki on the strength of a table that puts it second.

The hard boundary is platform. Local builds are supported only on Linux, and the README directs other platforms to a Vagrantfile or Codespaces. If you develop on macOS or Windows and need a runtime there, youki is not a candidate; you are looking at a Linux VM regardless. The kernel floor is 5.3, which rules out older long-term-support distributions without an upgrade.

There is also a documentation gap worth flagging. The repository root contains a MigrationGuide.md, which suggests version-to-version changes are tracked, but the README itself does not document rollback or how to downgrade a runtime that is already wired into containerd. The README does state that youki has passed containerd's e2e test and is used in production environments, with public examples collected on an adopters page, but that page is outside the README and its contents are not reproduced here.

## Maintenance, licensing and what an upgrade actually costs

The repository is not archived and the last push was on 2026-09-21, one day before this writing. Release cadence is slow and deliberate: v0.5.7 on 2025-11-05, v0.6.0 on 2026-02-25, v0.7.0 on 2026-07-25. That is roughly two releases a year, so you should not expect a fix to land the week you report it.

Licensing is Apache-2.0, which is permissive and includes an explicit patent grant. For most users of a container runtime this changes nothing operationally, but it does mean you can redistribute a modified youki binary. The workspace pulls in a large dependency tree, including libseccomp, libbpf-sys, wasmtime, wasmer and wasmedge-sdk across the various crates. Apache-2.0 on the runtime does not automatically describe the licences of those dependencies, and anyone redistributing a built binary should check them rather than assume. This is not legal advice; it is a reason to run a licence scan on the lockfile before shipping.

The upgrade cost is dominated by the spec, not the code. Because youki consumes config.json bundles produced by containerd or Docker, an upgrade usually means replacing one binary. The risk sits in behaviour changes that a container manager cannot see, which is what MigrationGuide.md at the repository root exists to record. Read it before moving between minor versions, and note that the workspace pins liboci-cli at 0.7.0 with a MARK comment, so CLI-level changes are versioned alongside the runtime.

## Conclusion

Adopt youki if you run Linux hosts at kernel 5.3 or newer, already drive containers through Docker, containerd or Podman, and want a runtime whose implementation language is Rust. Do not adopt it if you need Windows or macOS containers, if your kernel is older than 5.3, or if you expect the README to tell you how to roll back a version. Before putting it on a host, run ./youki info to confirm cgroup mode and namespace availability, and read MigrationGuide.md in the repository root for the upgrade path.

## FAQ

### What is youki?

youki is an implementation of the OCI runtime-spec written in Rust, described in its README as similar to runc. It is the binary a container manager such as containerd, Docker or Podman execs to set up namespaces, cgroups and mounts and start a container process.

### What does the name youki mean?

The README says youki is named after the Japanese word 'youki', which means 'a container'. It also notes the word can mean 'cheerful', 'merry' or 'hilarious', and gives the pronunciation as /joʊki/ or yoh-key.

### Which platforms can I build youki on?

Local builds are supported only on Linux, and the README requires Rust with edition 2024 and a Linux kernel of 5.3 or newer. For other platforms it points to a Vagrantfile or a preconfigured GitHub Codespace.

### Does youki work as a drop-in runtime for Docker or Podman?

The README's quick start shows youki passed as the runtime to docker run and to podman run with --cgroup-manager=cgroupfs and an explicit path to the binary. It also states that youki has passed containerd's e2e test.

### Is youki faster than runc?

The README publishes a hyperfine comparison and describes youki as having the potential to be faster and use less memory than runc, but the youki row in that table is version 0.3.3 while the latest release is v0.7.0. The same table shows crun ahead of youki, so the numbers are not a current guarantee.

## Sources

- [License: Apache-2.0](https://github.com/youki-dev/youki/blob/main/LICENSE)
- [Project website](https://youki-dev.github.io/youki/)
- [README](https://github.com/youki-dev/youki/blob/main/README.md)
- [Releases](https://github.com/youki-dev/youki/releases)
- [youki-dev/youki on GitHub](https://github.com/youki-dev/youki)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/youki-dev-youki