feat(images): add caddy-sablier image for VM scale-to-zero

[arunesh-j]

Adds images/caddy-sablier — Caddy with the Sablier scale-to-zero plugin compiled in. Consumed by the ZopDay deployer's new scale-to-zero VM component (zopnight, separate PR), which stops idle services on a VM pool and starts them again on the next request.

Why a custom image

The Sablier wake-on-request plugin is a Caddy module: it has to be compiled into the binary with xcaddy and cannot be loaded into a stock Caddy at runtime. Upstream publishes no prebuilt "Caddy + Sablier" binary, so we build one.

The two alternatives were worse: Caddy's official plugin download service always builds the latest Caddy (so we couldn't pin 2.11.3, see lockstep below) and makes every VM install depend on a third-party service being up; and building on the VM would need a Go toolchain everywhere.

It's a carrier, not a runtime

Nothing runs this container in production. ZopDay VM pools run Caddy as a host systemd service (it binds :80/:443 and reads /etc/caddy), so the component pulls the image and copies the binary out:

CID=$(docker create zopdev/caddy-sablier:v2.11.3)
docker cp "$CID:/usr/bin/caddy" /tmp/caddy && docker rm "$CID"

Docker Hub rather than a GitHub release asset because Docker is already a baseline component on every pool VM and those VMs already pull public images — no new registry auth, no new network path.

Version lockstep (the thing to know when bumping)

CADDY_VERSION must match the version the deployer's baseline caddy component installs. Both variants report the same version string and differ only by the extra dormant module — that is exactly what lets the component's skip-download gate treat them as interchangeable. Bumping one without the other makes every prep re-download the binary forever.

The build asserts both invariants the deployer depends on, so a bad bump fails here instead of on a VM six steps later:

1. caddy version matches ^v<CADDY_VERSION>
2. caddy list-modules contains http.handlers.sablier

The plugin is inert unless a sablier directive appears in the Caddyfile, so the binary is a safe drop-in replacement for stock Caddy of the same version.

Follows the existing image conventions

• images/caddy-sablier/{Dockerfile,README.md}, same layout as db-init / opentsdb
• Builds with the shared Image Deployment workflow, no workflow changes
• Publishes on tag caddy-sablier-image-v<N> → zopdev/caddy-sablier:v<N> + :latest
• README mirrors db-init's structure (Components & Versions, Prerequisites, Build, Usage, File Structure, Features, Publish, Contributing/CoC/License)

Tag with the Caddy version rather than an incrementing counter, so the published tag matches what the component requests — it derives the tag from its own CADDY_VERSION.

Verification

Built with the workflow's own invocation (context images/):

$ docker build -f images/caddy-sablier/Dockerfile -t caddy-sablier:prcheck images/
$ docker run --rm caddy-sablier:prcheck caddy version
v2.11.3 h1:/vFbdjcs2DtzcWTIxHybf5R5TspYFFThlZffChyBFHg=
$ docker run --rm caddy-sablier:prcheck caddy list-modules | grep sablier
http.handlers.sablier

Beyond the build, this exact image content was validated end-to-end before opening the PR: the rendered VM Caddyfile (route { sablier … { names …; dynamic } reverse_proxy … }) passes caddy validate against the binary, and a multi-arch build of it ran on a canary VM through a full sleep → wake cycle (idle service stopped, next request served the loading page, then the app).