Architecture

Dockyrd separates the control plane from the data plane, so managing your server never interrupts what it serves.

The three parts

• dockyrd runs on the host as a systemd service. It holds the API, the job runner, builds, the reconciler, metrics collectors, the updater and the embedded dashboard.
• Caddy runs as the dy-proxy container. Dockyrd sends it a complete JSON configuration through its admin socket; Caddy validates it atomically and keeps the old one if the new one is invalid.
• Docker Engine runs everything else. Each project has its own network, and only services with a public domain join the dy-edge network.

Desired and actual state

SQLite stores what should be running. Docker labels on every container, volume and network describe what is running:

dev.dockyrd.managed=true
dev.dockyrd.project=<project_id>
dev.dockyrd.service=<service_id>
dev.dockyrd.kind=app|database|redis|bucket|system
dev.dockyrd.deployment=<deployment_id>

Every 30 seconds, at startup and after each job, the reconciler compares the two. It restarts services that should run, removes leftovers from failed deploys, reloads the proxy if its config drifted and marks interrupted deployments as failed.

A zero-downtime deploy

1. Build the image dockyrd/<service>:<deploy>.
2. Start a new container next to the old one.
3. Wait for a TCP connection and, if configured, a 2xx from the health path.
4. Switch the Caddy upstream, move the internal hostname, and stop the old container after a 30-second grace period.

If the health check fails, the new container is stopped, its logs are kept and the old one stays live.

Why the binary runs on the host

One binary under systemd has the fewest moving parts. It reads host metrics from /proc directly, updates itself with an atomic file swap, and restarting it never restarts a container.