Your cloud · Docker
Docker: containers on your own terms.
Docker 29.9.2 is published as separate engine, client, Compose and Buildx packages. The engine uses containerd; package installation does not enable the daemon.

Install deliberately, enable explicitly
apk update
apk add docker-engine docker-cli docker-compose docker-buildx
# Saphira / OpenRC
rc-update add dockerd default
rc-service dockerd start
# Saphira-D / systemd
systemctl enable --now dockerd.service
docker run --rm hello-worldThe verified service is dockerd on both init systems. Images, writable layers and volumes live under /var/lib/docker; protect persistent volumes in backups, collect docker logs before deleting a failed container, and restart the daemon only with awareness that running containers can be affected.
Docker depends on the packaged containerd service. OpenRC expresses that dependency in dockerd’s init script and systemd expresses it in dockerd.service; enable and start containerd explicitly too when preparing a host from scratch.
What the packages provide
Each component is published as its own signed package. docker-engine (29.9.2) provides the dockerd daemon, matched against docker-cli (29.9.2), which supplies the docker client. docker-compose (5.6.0) adds multi-container application support, and docker-buildx (0.38.1) adds extended build capability. lazydocker (0.25.2) is a separate, optional terminal interface for Docker: a client that talks to the local daemon socket, not the engine itself.
The engine package ships service definitions for both editions: dockerd.initd for Saphira (OpenRC, foregrounded under supervise-daemon) and dockerd.service for SaphiraD (systemd), mirroring the approved upstream unit. The OpenRC script starts dockerd with --containerd=/run/containerd/containerd.sock, pointing it at the packaged containerd. Neither definition is enabled at install time, and one host need not carry every component: install precisely the packages a workload uses and leave the rest out.
Treat the daemon with respect
Docker networking changes host firewall behaviour. Treat Docker-daemon access as root-equivalent, keep registry credentials out of images and compose files, review published ports, and use named volumes rather than assuming a container filesystem is durable.
There is not yet a Saphira Docker deployment helper. Install and operate the packages deliberately on each host, keep the daemon disabled until required, and record the volumes, networks, published ports and restart policy that each application needs. Docker’s package split is useful precisely because a host need not carry every Docker component.
Docker upstream documentation explains Docker itself; it is not evidence that every workload has been tested on Saphira.