Celilo’s whole job is to deploy code — Caddy, Authentik, Homebridge, whatever you ask for. So the management server that runs Celilo should be no exception: it’s just another module. Instead of a bespoke installer and a hand-rolled setup interview, the control plane gets deployed with the same Ansible, hooks, and capability resolution Celilo already applies to everything else.
Why this matters
Today the management server has its own special path — a shell installer plus a
one-off celilo system init interview — and none of it uses the real Celilo
toolchain. That means the one machine Celilo can’t rebuild with its own tools is
the machine Celilo runs on. If you want a second management box, or need to
recover a crashed one, you’re back to doing it by hand. Turning the control plane
into a celilo-mgmt module closes that gap: the thing that deploys everything can
finally deploy itself.
A tiny bootstrap, then a normal deploy
You genuinely can’t run celilo until the runtime is on disk, so bootstrapping
shrinks to the irreducible minimum — one command that installs just enough to get
the CLI, then hands off:
curl -fsSL https://celilo.computer/bootstrap.sh | bashFrom there, everything is an ordinary module deploy. The celilo-mgmt module’s
own Ansible role installs the rest of the dependencies, initializes and migrates
the database, sets up the daemon, and runs the same module-config interview any
module uses. The old system init interview goes away because the module already
handles it.
Recovery and standbys become routine
Because the management server’s entire state — database, per-module Terraform state, encryption key, machine pool — is captured by the module’s backup hooks, recovering a lost control plane is bootstrap plus a restore. Want a hot standby? Bootstrap the standby and restore from the primary’s backup, and you have an identical box ready to take over. The special case disappears; the control plane is deployed, backed up, and upgraded exactly like every other module in the fleet.