Self-hosted infrastructure

The five machines behind my homelab.

The homelab is a five-node Proxmox cluster I have run since 2020 for about 60 regular users: routing and DNS at the edge, a self-hosted Git forge with its own CI/CD, and about twenty services behind one Traefik reverse proxy. The numbers on this page are a snapshot captured at build time.

Five nodes, each with a job

One Proxmox cluster, five hosts. The readout on each card is a snapshot from the cluster’s own Proxmox API, captured once and shown as of the date below.
Cluster load
nodes online
5/5
VMs and containers running
28/33
endpoints up
26/26
CPU10%
memory35%

CPU and memory over the last week, one point every 8 h · as of Sep 23, 2026

edge

2 CPU · 3.7 GB

The edge. The VyOS router, Traefik, and uptime monitoring.

CPU
18%
memory
56%
uptime
46 days

apps

2 CPU · 11.6 GB

Self-hosted apps and sites, plus LAN DNS and Home Assistant.

CPU
7%
memory
43%
uptime
14 days

aux

2 CPU · 7.6 GB

A small spare node: a second router VM and the VM templates.

CPU
3%
memory
50%
uptime
46 days

core

4 CPU · 31 GB

The workhorse. A Git forge, the CI runners, Nextcloud, a PaaS.

CPU
26%
memory
29%
uptime
14 days

gpu

12 CPU · 32 GB · GTX 1050

Capacity and GPU. The media stack, the Kubernetes VM, and local LLM inference.

CPU
4%
memory
33%
uptime
6 days

as of Sep 23, 2026

How a request reaches a service

Every hit on one of my self-hosted apps crosses the same path, from the public edge to the backend that answers it.
  1. Visitora browser
  2. CloudflareDNS
  3. VPSWireGuard
  4. VyOSthe router
  5. TraefikTLS, routing
  6. appsself-hosted apps

How a self-hosted project ships

A push to main runs three jobs on a self-hosted runner and lands live in about two minutes, with an automatic rollback if the smoke test fails. This exact site (built with Astro, shipped to GitHub Pages) uses a different pipeline; this is the one behind my self-hosted projects.
  1. ~45 sverifylint, types, build, and the smoke tests
  2. ~50 simagebuild, scan with Trivy, push to the registry
  3. ~15 sdeploypull, smoke test the live URL, roll back on failure

A representative run of the pipeline behind my self-hosted services.

The stack that holds it up

Standard, widely used tools.
  • Proxmox VEThe five-node hypervisor cluster
  • VyOSThe router at the edge
  • WireGuardTunnel to the public VPS
  • TraefikReverse proxy, Let’s Encrypt certs
  • DockerEvery service, containerized
  • Gitea + ActionsSelf-hosted forge and CI/CD
  • Cloudflare DNSDNS and the ACME challenge
  • AdGuard HomeLAN DNS with filtering
  • TailscaleNomad access to the LAN
  • CoolifyA small PaaS for the side apps

Operated end to end

Backups, monitoring, and a written procedure for each recurring operation.

  • Run by one person

    I handle backups, certificate renewal, monitoring, and incidents myself.

  • Watched from two sides

    Uptime Kuma inside the cluster, and Gatus on an outside server, so an outage of the cluster cannot hide its own alert.

  • Runbooks in a private repo

    The cluster’s setup, runbooks, and automation live in a private versioned repo. Adding a node or restoring a service follows a written procedure.