Skip to content

rack-01 · Proxmox · Talos · Flux

A homelab run like a small platform team.

Six hosts in one rack, Kubernetes on Talos, and every change shipped through Git. The decisions are written down, the failures have runbooks, and every recovery path is tested or removed.

Read the docs github.com/igresc

Designed, built and operated solo by Sergi Castro.

$ tree -L 3 homelab
homelab
├── kubernetes/clusters
│   ├── staging      # Flux → Talos, tracks main
│   └── prod         # staged for the Talos move
├── terraform        # OpenTofu: VMs, DNS, Talos
├── ansible          # hosts outside Kubernetes
└── docs             # this site, canonical copy
$
6
hosts: five compute hosts, one TrueNAS
10 GbE
aggregation core, 1 GbE access
11
architecture decision records
24
runbooks, 11 wired to alerts

01 · Hardware

Rack-01, top to bottom.

Five compute nodes, a TrueNAS storage server and a 10 GbE aggregation layer in one rack. Positions mirror NetBox, half-units and all.

compute storage network NetBox export · 20 Aug 2026

Compute and storage

HostHardwarePlatformSlot
pve2 MS-01 Proxmox VE U25 · A
pve4 MS-01 Proxmox VE U25 · B
pve1 Whitebox, Ryzen 7 2700 Proxmox VE U20.5
nebula Whitebox, Core i7-6700K TrueNAS U16.5
pve5 Whitebox, Core i7-6700 not recorded U12
pve3 Whitebox, Core i5-12600K Proxmox VE U7.5

Network

usw-aggregation-01

Ubiquiti USW-Aggregation. The 10 GbE SFP+ core between hosts and storage.

css326-01

MikroTik CSS326-24G-2S+. Gigabit access with two SFP+ uplinks.

pfSense

The edge firewall, driven over its REST API with pfRest.

02 · Platform

Four layers, one owner each.

Every layer keeps its desired state in Git, and exactly one tool writes to it. When something drifts, there is never a question of who is supposed to fix it.

  1. L1 Infrastructure OpenTofu Proxmox VMs, DNS, Talos configuration, cluster bootstrap
  2. L2 Kubernetes Flux Platform controllers and applications, once the cluster is bootstrapped
  3. L3 Hosts Ansible Everything that runs outside Kubernetes, like the Docker host
  4. L4 Runtime secrets OpenBao + External Secrets Secret storage, auto-unsealed by GCP Cloud KMS, delivered to apps

Compute and OS

  • Proxmox VE
  • Talos Linux
  • k3s
  • TrueNAS
  • Docker

Kubernetes

  • Flux
  • Cilium
  • Longhorn
  • Traefik
  • External Secrets

Observability

  • OpenTelemetry
  • Loki
  • Grafana
  • ntfy
  • Uptime Kuma

Cloud and state

  • GitHub Actions
  • GHCR
  • GCS state
  • Cloud KMS
  • Backblaze B2

03 · Delivery

Git is the only way in.

Staging runs Talos and tracks main. Production still runs k3s from a separate GitOps repository while it moves to the same Talos topology.

Staging · igresc/homelab

  1. Pull requestbranch
  2. GitHub Actionsvalidate
  3. mainmerge
  4. Fluxclusters/staging
  5. Talos stagingreconciled

Production · igresc/gitops

  1. igresc/gitopsseparate repo
  2. Fluxreconcile
  3. k3s productionrunning today
  4. Talos productionmigration target

Target topology

Three control planes, three hosts

Each control-plane node sits on a different Proxmox host, and applications share those same nodes.

Network and storage

Cilium and Longhorn

Cilium is the CNI and installs at bootstrap, before Flux. Longhorn provides persistent volumes.

Ingress

Traefik behind the edge

Public traffic lands on Traefik. This site is built as an image and served from Talos behind it.

04 · Decisions

Written down before it's built.

Architecture decision records explain the why. They describe the accepted design, which can run ahead of what is deployed, and each one says where it stands.

ADR 001 rollout pending Keep the homelab in a monorepo ADR 002 rollout pending Manage the Talos cluster lifecycle with Terraform ADR 003 Use Cilium for Talos networking ADR 004 rollout pending Collect telemetry with OpenTelemetry into Mimir and Loki ADR 006 rollout pending Backups and rebuild ADR 007 rollout pending Run Talos as three hyperconverged nodes on three hosts ADR 008 rollout pending Use Longhorn for persistent storage ADR 009 rollout pending Use OpenBao as the secret authority ADR 010 Store Terraform state in Google Cloud Storage ADR 011 rollout pending Change flow and promotion ADR 012 rollout pending What to self-host Browse all decisions ──›
The rule, from ADR 012
"Self-host what teaches something, saves money, or keeps personal data private."

Use a SaaS when it is free or cheap, holds no personal data, and running it teaches nothing.

Free day to day

Keep a recovery measure if it costs nothing day to day: a one-time setup, or a job that runs on its own and alerts when it breaks.

No tax on every change

Cut anything that adds a step to every change, unless it covers a failure that happens about once a year.

Data strict, rebuilds slow

Protect data hard. For rare disasters, a slow manual rebuild is an accepted cost.

Tested, or removed

Every recovery path gets a first test and a place in the yearly drill rotation. Otherwise it goes.

05 · Operations

When it breaks, there's a page for that.

Every alert links to its runbook. The alert endpoint is planned off-site, so it keeps working when the lab is down.

Outside the blast radius

An off-site watchtower

ADR 004 puts ntfy and Uptime Kuma on a free-tier Oracle Cloud VM, so a dead lab can still page. The lab checks the VM in turn, because Oracle reclaims idle free-tier VMs. Not built yet.

Procedures · 13 runbooks

The manual is public.

Architecture, decisions, runbooks and service guides. The same pages used to run the lab, kept in the repo next to the code they describe.

Read the docs