Uses

Where I keep the repositories, run CI, and record work in issues. It has its own VM. Linux runners handle x86-64 and ARM64 jobs; macOS and Windows runners power up when needed.

The five-node cluster that runs the VMs and containers underneath the lab.

Shared storage for the Proxmox cluster and the workloads running on it.

Runs the applications. I manage the nodes through an API rather than logging in over SSH.

Applies the Kubernetes configuration from git. I can revert a configuration change there too, then check that the application recovered.

Defines and provisions the Proxmox VMs and LXC containers.

Configures the hosts and services below Kubernetes, so their setup is recorded alongside the rest of the infrastructure.

For building container images and testing services locally.

A firewall pair with CARP failover handles routing for the lab. Needing a couple of settings that were missing from its interface led to two upstream contributions, six years apart.

Handles Kubernetes networking and advertises service addresses over BGP so the rest of the network can reach them.

Routes web requests into the cluster and handles TLS at the ingress.

The internal DNS resolvers. dnsweaver updates the service records as workloads change.

Public DNS and the edge in front of these sites.

Postgres with automated failover, on dedicated VMs. Keeping it outside Kubernetes means the database does not need that cluster running to start.

For applications that need MySQL-compatible storage or a Redis-compatible service.

The metrics and dashboards I use to see what the lab is doing. Alertmanager sends the alerts.

Stores the credentials that services need at runtime, with External Secrets supplying them to Kubernetes.

The glue and the scripts that run the lab, and my preference anywhere it will run. PowerShell when I have no choice, with the reference docs open.

Runs CI on the public repositories, including tests and CodeQL checks.

Opens updates for dependencies and container images so I can review them instead of checking versions by hand.

Debian on the development VM and Talos on the Kubernetes nodes.

I work through the design with agents and have them implement it. For scheduled jobs, I start by asking for reports and check the results before deciding whether to allow specific changes.

I keep changes small enough to review and use git to record what the infrastructure should look like.

Runbooks give me somewhere to start when a problem comes back. Architecture decision records explain why I chose something, which is easy to forget after a few months.