Celilo’s source code now lives on Celilo’s own Forgejo instance. Rather than renting a home for the code on someone else’s platform, the forge is deployed the same way everything else in the lab is: as a Celilo module. The git host that stores Celilo is itself a Celilo deployment — infrastructure that proves the system by running on it.
Dogfooding the whole stack
The forge isn’t a special case. It’s a module in the app zone, provisioned onto
a container like any other, fronted by the same public_web capability that
routes every other web service through Caddy for TLS. Its authentication runs
through Authentik with single sign-on, and its data rolls into the same backup
infrastructure that protects the rest of the lab. Nothing about hosting the
source code required a bespoke pipeline — it required writing one more module.
Your code, reachable on your terms
Forgejo (an open-source, AGPL-licensed git forge) speaks the protocols
developers already use: HTTPS for browsing and cloning, and git over SSH for
push and pull. Both are exposed deliberately through Celilo’s own capabilities —
Caddy terminates TLS on the web side, and the firewall forwards the SSH port —
so git clone and git push work against a real address you control. Access is
gatekept by single sign-on, not by hoping nobody finds the URL.
Why it matters
Owning the forge means owning the whole loop: where the code lives, where pull requests happen, and where releases originate. It removes a dependency on an outside service and turns the project’s own infrastructure into the proof that the infrastructure works.