2026-09-30 –, Galerie
sdme is a single static binary that boots systemd-nspawn containers using copy-on-write roots (overlayfs layers or btrfs snapshots), with OCI registry pulling and Kubernetes Pod YAML support. No daemon, no runtime dependency beyond the systemd you already run.
Why I built it. Every container runtime reinvents what systemd already does well: process supervision, logging, cgroups, service ordering, socket activation. sdme makes the opposite bet. systemd-nspawn already boots a full system in isolation; the kernel already gives it a cheap copy-on-write root, whether through overlayfs or a btrfs snapshot. Put a thin, daemonless CLI over the two and you get container workflows (clone, import, pull, run) without a new runtime to install or a daemon to keep alive. It began as a one-command clone of the running host, but the bet is bigger than that: lean on the init system instead of rebuilding it.
What you get. Proper machine-like containers: each one runs a full systemd init with journald, D-Bus, and systemctl, not a single foreground process. Each container is highly configurable through native systemd surfaces, with per-container resource limits, networking, and drop-in config. Clone your running host into a throwaway container in one command; run a Docker Hub image (nginx, redis, postgres) as a managed systemd service instead of a foreground process; deploy a multi-container pod from Kubernetes Pod YAML with health probes, secrets, and configmaps. A rootfs can also come from any distro, an OCI registry, a tarball, or a QCOW2 image, and you can build your own from a Dockerfile-like config.
How it works. One copy-on-write root and one systemd-nspawn invocation give you a fully booted system. Storage is pluggable per container. The overlayfs backend mounts the host / (or any imported rootfs) as an immutable lower layer with a fresh upper, so clones are instant. The btrfs backend snapshots the base rootfs as a subvolume instead, which makes the container root a real filesystem: nested containers work, user namespaces use native idmapped mounts, and per-container disk quotas come from qgroups. It runs directly on a btrfs data directory, or inside a loopback pool image on any other filesystem. The binary does two jobs: it manages those copy-on-write roots, and it drives systemd over D-Bus to start, stop, and supervise containers. Everything else (init, journald, cgroups, service ordering) is systemd doing what it already does, with no daemon in the middle.
Twenty-plus years in systems engineering and infrastructure.
Currently an engineering manager at Meta; sdme is a personal project,
built on weekends and evenings. Lifelong Linux user, occasional contributor
across the stack. Lives in London, UK.