The canonical way to install Celilo on a production Linux box is the way you
install anything else: apt install celilo. A signed Debian package, served
from Celilo’s own apt repository, replaces the old curl … | bash bootstrap as
the front door. You add the repo once, then celilo installs, upgrades, and
removes through the standard tooling every operator already trusts.
Why apt
Piping a script from the internet into bash asks operators to take a lot on
faith. apt doesn’t: it verifies the repository’s signed release metadata before
installing anything, so the package’s authenticity is checked for you. Upgrades
flow through apt upgrade — predictable, reversible, and well understood — which
means there’s no separate “celilo self-update” command to learn. apt upgrade celilo is the upgrade mechanism.
A thin package over a real install
The .deb itself is tiny — a wrapper script plus a little metadata. The actual
Celilo code arrives as the @celilo/cli package at install time, materialized
into /var/celilo alongside its pinned toolchain. That directory holds the
state that matters — the database, the master encryption key, and the Terraform
state describing what’s been provisioned — and it survives every upgrade
untouched. A dedicated celilo system user owns it, so nothing runs as root
that doesn’t have to.
Built for real hardware
Packages ship for arm64 and amd64 from day one — the Raspberry Pi running a
management node and the amd64 hosts in the lab are equally first-class. Removing
the package leaves your state in place; only an explicit apt purge touches it,
and even then it asks first and defaults to “no.” Losing a master key to a
routine cleanup shouldn’t be possible by accident.