2026-09-30 –, Galerie
sdme is a single static binary that boots systemd-nspawn containers using
overlayfs copy-on-write layers, 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; overlayfs already gives it a cheap copy-on-write root. 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 overlayfs mount (host / as the lower layer, a fresh
upper) and one systemd-nspawn invocation give you a fully booted system. The
binary does two jobs: it manages the overlayfs layering that makes each
container a cheap copy-on-write root, 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.
sdme is built on two things every modern systemd distro already has:
systemd-nspawn and overlayfs. There is no daemon and no runtime to install.
The binary has two jobs: manage the overlayfs layering that gives each
container a cheap copy-on-write root, and drive systemd over D-Bus to start,
stop, and supervise containers. Everything a running system needs (init,
journald, cgroups, service ordering, socket activation) is systemd doing what
it already does.
A few properties fall out of that design:
-
Machine-like containers. Each container boots a full systemd init, not a
single foreground process, so it behaves like a small machine: journald for
logs, D-Bus,systemctl, and per-container resource limits, networking, and
drop-in config through native systemd surfaces. -
Daemonless and crash-safe. With no long-running daemon, all state lives
on disk, guarded by cooperative file locking and transactional staging. A
mutation either commits atomically or leaves nothing behind, so an
interrupted operation never corrupts a container. -
OCI-native. Images pull straight from any OCI registry with
content-addressed verification, and an OCI app runs as a managed systemd
service on a minimal rootfs. A rootfs can also come from another distro, a
tarball, or a QCOW2 image. -
Pods on nspawn. A pod is a set of containers sharing one network
namespace, the Kubernetes model, built from standard Pod YAML with init
containers, health probes, and secrets and configmaps surfaced as files.
The throughline is one bet: lean on the init system instead of rebuilding it.
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.