Vision

The problem with home labs

Home labs are fascinating machines — half museum, half chaos. A Raspberry Pi running Pi-hole. A Proxmox cluster someone built from old workstations. A VPS with a reverse proxy configured by hand six months ago, now unmaintainable.

The problem isn't that people don't know what they're doing. The problem is that no good tooling exists for this scale. Kubernetes is designed for teams. Nomad needs a cluster. Terraform alone doesn't know about your DNS provider. Ansible doesn't know what services you have running. Each tool does one thing — and wiring them together is left as an exercise for the reader.

The result: every home lab is unique, undocumented, and unmaintainable by anyone but its owner. Most can't be rebuilt from scratch. Many drift from their intended state over years of ad-hoc changes. And migrating to new hardware is a weekend project that stretches into a month.

The Celilo approach

Celilo treats your home lab as a collection of modules — each one a well-defined unit of infrastructure with clear inputs, outputs, and dependencies. A module declares what it needs (a DNS registrar, a firewall, a container host) and what it provides (a public web endpoint, an identity provider, a DNS server). Celilo wires them together.

This is the same principle that makes large-scale infrastructure manageable: declarative state, dependency resolution, typed interfaces. Celilo brings these ideas down to the scale of one person with a few machines and a domain name.

Capabilities, not configuration

Celilo solves this with the capability system. Instead of configuring modules with raw hostnames and IP addresses, modules declare what capability they need: dns_registrar, public_web, firewall. Celilo resolves those dependencies at deploy time, injecting the right implementation wherever it's needed.

This means:

• You can swap your DNS provider without reconfiguring every module that uses DNS.
• You can add a second domain and it works everywhere automatically.
• Modules written by others work with your infrastructure — they don't need to know the specifics.

The capability system is what lets Celilo be both opinionated and flexible. Modules follow conventions, but the implementations are pluggable.

Dogfooding as a design principle

This website is a Celilo module. The registry that serves these modules is a Celilo module. The DNS records for celilo.computer are managed by the Namecheap module. The TLS certificates are handled by the Caddy module.

Every piece of infrastructure that runs Celilo itself was deployed using Celilo. This is intentional. If something is painful to express as a module, that pain surfaces immediately during development — not later, when real users hit it. The tool must be pleasant to use for real work, not just in demos.

Where we're going

Celilo v1 focuses on the core: module lifecycle, the capability system, and a registry of well-crafted official modules. The goal is to make the common home lab scenarios — DNS, reverse proxy, identity, smart home — genuinely pleasant to run.

From there, the module ecosystem grows. Community modules. Better observability. A declarative "desired state" model that can detect and repair drift. Multi-user support for shared home labs.

The north star: your home lab should be as easy to rebuild as it was to build the first time. That's what Celilo is for.