Homelab & infrastructure experiments

What this is

This page is a lab log, not a product. It collects the infrastructure I actually run for my own work and the things I am testing on top of it. Entries are labelled by status so nothing here reads as finished when it is not:

Status	Meaning
Running	In use now, for something real
Testing	Working on it, not trusted yet
Planned	Written down, not built

Running

Static sites as containers. Personal sites are built in a Node stage and served by a Caddy image. The build is reproducible from the repository, the runtime image is small, and deployment does not depend on the host having Node installed. The Containerfile for this site is the current example of that pattern.

One process per container. Each service owns its own image and data directory instead of sharing a long-running host with everything else. It makes upgrades and rollbacks boring, which is the point.

Reverse proxy in front, TLS at the edge. Caddy terminates TLS and forwards to containers by name. Certificates are renewed automatically; service containers never handle public certificates themselves.

Linux as the operating system, not a detail. Deployment, logs, permissions, and the firewall are all things I configure and read directly. Working from a terminal is the default, not a fallback.

Testing

Service isolation on a private network. Moving services onto a Podman network where only the proxy is reachable from outside, instead of publishing ports directly. The open question is how much of the setup to express in compose files versus systemd units.

Backups and restore paths. A backup that has never been restored is a hypothesis. The work here is writing down the restore procedure and testing it on a throwaway volume before trusting the schedule.

Monitoring without a platform. Logs, systemctl status, and a small uptime check are usually enough for a handful of services. I am testing where the line is before a full monitoring stack becomes justified.

Planned

• A documented disaster-recovery note for every self-hosted service: where the data lives, how it is backed up, and how to rebuild it.
• Resource limits per container so one runaway service cannot take the host down.
• A network diagram of the lab that stays accurate — the current one lives in my head, which is not a reliable storage medium.

What I am trying to learn

The goal is not to run as many services as possible. It is to understand the failure modes: what happens when a container restarts mid-write, when a certificate expires, when DNS points at the wrong host, or when a disk fills up at night.

That is the same set of concerns that matters in the university systems I work on, just with lower stakes and more freedom to break things. When a pattern survives here, I trust it more in production.

Related notes

Container deployment and reverse-proxy setup are written up in the engineering notes:

• Shipping a static site as a container
• Default to the server