BEYOND DOCKER

Kiri on Linux

On Linux, Kiri doesn’t need a VM: the machine already has a Linux kernel. The same kiri daemon and the same guest agent that run inside the VM on a Mac run straight on the host here, and the docker CLI, Compose and buildx talk to it as usual.

No VM, same engine

On a Mac, the daemon boots a small Linux VM and talks to the agent inside it over vsock. On Linux, the agent (kiri-init) is started as an ordinary root process on the host’s kernel, and the vsock ports become unix sockets in a private directory. Everything above that is unchanged: each container is still one clone3 into new namespaces and its cgroup, with overlayfs, capabilities and the seccomp filter. No dockerd, containerd, shim or runc.

The same engine on both. On the Mac the agent is PID 1 in a VM, reached over vsock; on Linux it's a process on the host, reached over unix sockets.

What doesn’t apply on Linux: the window and menu bar, kiri setup and kiri update are Mac-only, and there’s no memory balloon, since there’s no VM to give memory back from.

Packages

There are two packages, in .deb (Debian, Ubuntu) and .rpm (Fedora, RHEL, openSUSE) form. The binaries are static, so one package runs on every distribution.

Package	Contents	File names
`kiri`	The engine, plus the `docker` CLI, Compose and buildx	`kiri_<version>_amd64.deb`, `kiri-<version>-1.x86_64.rpm`
`kiri-lite`	The engine alone, for machines that already have a `docker`	`kiri-lite_<version>_amd64.deb`, `kiri-lite-<version>-1.x86_64.rpm`

The packages are built for x86-64. The engine itself builds for arm64 and x86-64; on an arm64 machine, install it from source with the systemd unit (below).

What a package installs:

/usr/bin/kiri and /usr/bin/kiri-init.
kiri.service, enabled and started on install where systemd runs.
The kiri group, which owns the socket /run/kiri/docker.sock.
State in /var/lib/kiri-daemon (0700), images and containers in /var/lib/kiri (0710).
The full kiri package also adds its docker CLI, with Compose and buildx in /usr/lib/docker/cli-plugins. It offers docker on your PATH through update-alternatives only when /usr/bin/docker is missing or already an alternatives link, so a docker another package installed keeps winning. Kiri’s docker talks to Kiri’s socket unless DOCKER_HOST, DOCKER_CONTEXT or a context of your own says otherwise.

Install

Install the package:

sudo apt install ./kiri_<version>_amd64.deb
# or
sudo dnf install ./kiri-<version>-1.x86_64.rpm

Join the kiri group, so you can use Kiri without sudo, then sign out and back in:
```
sudo usermod -aG kiri $USER
```
Run something:
```
docker run --rm hello-world
```

With kiri-lite, point your own docker at Kiri first:

bash

$ docker context create kiri --docker host=unix:///run/kiri/docker.sock
$ docker context use kiri

Upgrades and removal

Upgrading the package leaves the running engine as it is, because stopping it would end every container. Restart it when it suits you to run the new version:

sudo systemctl restart kiri

Removing the package keeps your images, containers and state in /var/lib/kiri and /var/lib/kiri-daemon. apt purge deletes them too.

From source, with systemd

contrib/linux/kiri.service in Kiri’s source runs the engine as a systemd service without a package. Build with cargo xtask linux, copy kiri and kiri-init from target/linux/release to /usr/local/bin, then:

sudo cp kiri.service /etc/systemd/system/
sudo groupadd -f kiri
sudo systemctl enable --now kiri

The unit runs kiri daemon as root with KIRI_SOCKET=/run/kiri/docker.sock and KIRI_SOCKET_GROUP=kiri, and Delegate=yes, because the daemon creates the cgroups its containers run in. Users in the kiri group then create the context as above.