GET STARTED

Features

Kiri is one app that gives your Mac a Docker engine. This page lists what it does today, grouped by area. Each item links to the page that explains it.

What runs where

On your Mac there are three parts: the docker CLI (with Compose and buildx), the Kiri app with its window and menu bar, and the kiri daemon, which the app starts at login. The daemon serves the Docker Engine API on ~/.kiri/run/docker.sock and owns one small Linux VM. Inside the VM, Kiri’s guest agent runs as PID 1 and starts every container itself, with no dockerd, containerd or runc.

Every docker command and the window go through one socket to the kiri daemon on the Mac. The daemon talks to the guest agent in the VM over vsock; the agent starts the containers.

How it works explains each part in more detail.

Docker

Kiri speaks the Docker Engine API, so the tools you already use work with it unchanged.

Containers: run, exec, logs, attach, stop, restart, pause, stats, top, diff, commit, cp and the rest, with memory, CPU and PID limits, Docker’s default capabilities and a seccomp filter. Container records survive a daemon restart.
Images and Rosetta: pull with your docker login credentials, push, save, load, search. amd64 images run through Rosetta, and --platform is honoured.
Builds: docker build and buildx build run on BuildKit in a Kiri container, which stops when it’s idle.
Compose: up, down, ps, logs, exec, with several networks per project.
Volumes and mounts: named and anonymous volumes, bind mounts of Mac folders over virtiofs, --tmpfs and --mount.
Moving from Docker Desktop: kiri import brings images, volumes and containers over from OrbStack or Docker Desktop.

Docker’s commands also work as kiri commands (kiri run, kiri ps, kiri compose up), which always use Kiri, whatever docker context is selected. See Command line and CI.

Networking and names

Networks and ports: a default bridge, user networks with DNS by name and alias, --network host and none, and -p for TCP and UDP. Published ports listen on all interfaces, as Docker’s do; -p 127.0.0.1:8080:80 keeps one local. host.docker.internal reaches the Mac.
Domain names: every running container answers at http://<name>.kiri.localhost with no setup, or at http://<name>.kiri.local once you turn that on. Compose services answer at <service>.<project>.kiri.local, and a dev.kiri.domain label picks a container’s own names.
HTTPS: the same names over https://, with Kiri’s own certificate authority. It can only vouch for *.kiri.local and *.kiri.localhost.

Files and the SSH agent

Container files in Finder: each running container’s files appear under ~/Kiri, read-only and always current. Nothing is copied up front; Finder reads them from the VM when you open them.
SSH agent: containers reach your Mac’s SSH agent at /run/host-services/ssh-auth.sock, so git over SSH works inside without copying keys.

The app

The window: containers, images, volumes and networks, with Compose projects grouped so you can start, stop or remove a whole project. Each container has its own page with details, live logs, a terminal and its files. The Pull box searches Docker Hub as you type.
Menu bar: Kiri stays in the menu bar when the window closes, with the VM’s state, the running containers and a Start or Stop button.
Settings: fonts and text size, the VM’s CPUs and memory, a proxy, imports from other engines, and local names.
Memory and sleep: the VM gives unused memory back while it runs, and sleeps after 60 seconds with nothing running. It wakes in about 0.15 s.
Updates: the window offers new releases, downloads them in the background and checks their checksum, signature and notarization before installing.

Kiri

ContainersImagesVolumesNetworksSettings

Containers

shopCompose · 2 of 2 runningStop all⋯

webweb.shop.kiri.localUp 4 minOpenStop⋯

redisredis:7Up 4 minStop⋯

docsnginxExited (0) 2 h agoStart⋯

Kiri 0.1.4Linux VM running · 3 of 4 running · docker → kiri

The window lists containers with their names, state and ports. A Compose project is one group; a container reachable by name gets an Open button.

Kubernetes and Linux machines

Kubernetes: kiri k8s start runs a single-node k3s cluster in one container, ready in about 20 s, as the kiri kubectl context. LoadBalancer services are published on localhost.
Linux machines: kiri machine create dev --distro ubuntu makes a long-running Linux machine with your user, sudo, and /Users at the same path. Ubuntu, Debian, Alpine, Fedora, Arch, Rocky and openSUSE, with --systemd if you want systemd as init.

Other platforms

Kiri on Linux: the same engine with no VM, running on the host’s kernel. Packaged as .deb and .rpm: kiri with the docker CLI, Compose and buildx, or kiri-lite for the engine alone.
Kiri on Windows: experimental. A per-user installer, the same window, and the engine in a WSL2 distro, with no change to your network settings.

Quick startInstall Kiri and run your first container.How it worksThe VM, the agent, and how a container starts.BenchmarksMeasured against Docker Desktop and OrbStack.