Robin Miller

Familie und Freunde nutzen meine Dienste jeden Tag — das Lab läuft also produktiv und rund um die Uhr. Fällt etwas aus, habe ich schnell genug Leute am Telefon, die sich beschweren. Gleichzeitig ist es mein Labor: Hier probiere ich Technologien aus, bevor ich sie ernst nehme.

Cluster

2 × Proxmox VE + Quorum-Gerät

Dienste

30+ self-hosted

Backup

Proxmox Backup Server, versioniert

Doku

100 % als Git-Repo (Docs as Code)

• Zwei-Node-Cluster mit externem Quorum-Gerät — ein Node kann ausfallen, ohne dass der Cluster die Mehrheit verliert
• Thunderbolt-Direktverbindung zwischen den Nodes — Replikation und Live-Migration laufen über eine eigene, sehr schnelle Leitung statt über das normale Netz
• Segmentiertes Netz: getrennte VLANs für Infrastruktur, Dienste, Clients, DMZ und IoT
• Kein offener Port nach Hause — externe Dienste laufen über einen VPS (Pangolin mit Traefik als Reverse Proxy, CrowdSec als WAF) und von dort durch einen verschlüsselten WireGuard-Tunnel; intern verteilt Caddy
• Eigene Firewall (OPNsense) mit strikten Regeln zwischen den Segmenten
• Zwei Wege, ein Repo: Debian-Hosts betreiben ihre Dienste als Docker-Compose-Stacks, die Ansible ausrollt — NixOS-Hosts sind komplett als Flake deklariert und bauen sich bei jedem Push selbst neu
• Updates nach fester Policy: Betriebssysteme unbeaufsichtigt im Wartungsfenster, App-Updates gesammelt nach Freigabe
• KI-Agenten als Teammitglieder: Planung, Umsetzung und Review in getrennten Rollen, jede Änderung als Commit nachvollziehbar
• Secrets ausschließlich verschlüsselt im Repo (SOPS / age)
• Monitoring & Alerting für Dienste, Platten und Backups — Meldungen kommen per Push aufs Handy

Drei kurze Ausschnitte aus meinem Homelab-Repository — für die Veröffentlichung umgeschrieben und anonymisiert, aber echt in Struktur und Stil. Aufklappen zum Lesen.

- name: Update LXC containers in controlled batches
  hosts: lxc_all
  serial: 5
  tasks:
    - name: Apply pending upgrades
      ansible.builtin.apt:
        update_cache: true
        upgrade: dist

    - name: Health check — compose stack still running?
      ansible.builtin.command: docker compose ps --status running -q
      args:
        chdir: /opt/{{ service_name }}
      register: health
      changed_when: false
      failed_when: health.stdout == ""

    - name: Hold host for manual review instead of rolling on
      ansible.builtin.file:
        path: /var/lib/updates/hold/{{ inventory_hostname }}
        state: touch
      when: health is failed

# hosts/webapp01.nix — the whole host, declared in one file
{ config, ... }:
{
  imports = [ ../modules/lxc-base.nix ];   # hardening, SSH keys, updates

  networking.hostName = "webapp01";
  networking.interfaces.eth0.ipv4.addresses = [
    { address = "192.0.2.10"; prefixLength = 24; }   # documentation range
  ];

  services.nginx = {
    enable = true;
    virtualHosts."webapp.example.org".root = "/srv/webapp";
  };

  # only what is declared is open — everything else is dropped
  networking.firewall.allowedTCPPorts = [ 80 ];

  # secrets are decrypted on the host at activation, never stored in git
  sops.secrets."webapp/token".owner = "nginx";
}

endpoints:
  - name: webapp
    group: services
    url: "https://webapp.example.org/health"
    interval: 2m
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 1500"
      - "[CERTIFICATE_EXPIRATION] > 168h"   # a week's warning
    alerts:
      - type: ntfy
        failure-threshold: 3    # one hiccup is not an incident
        success-threshold: 2
        send-on-resolved: true

alerting:
  ntfy:
    url: "https://ntfy.example.org"
    topic: "homelab-alerts"
    priority: 4

1. 01 Einfach schlägt clever

   Im Beruf

   Die einfachste Lösung, die das Problem wirklich löst, ist die stabilste — weniger bewegliche Teile heißt weniger, was nachts um drei ausfallen kann.

   Im Homelab

   Nur ein stabiles Homelab ist ein gutes Homelab. Eine einfache Lösung, die jeden Tag läuft, schlägt die clevere, die eine Nische abdeckt und jede Woche ausfällt — oder die ich nach einem Jahr selbst nicht mehr verstehe.

2. 02 Einheitlich statt Einzelstück

   Im Beruf

   Gleiche Systeme werden gleich aufgebaut: Clients und Server bekommen ihre Einstellungen zentral über Gruppenrichtlinien, das Netzwerk wird über die LANCOM Management Cloud aus einheitlichen Vorlagen ausgerollt. So versteht jeder im Team jedes Gerät, und Abweichungen fallen sofort auf.

   Im Homelab

   Feste Konventionen für Namen, Netze und Deployments; eine Ausnahme wird bewusst entschieden und dokumentiert, nicht einfach gewachsen.

3. 03 Notfallpläne werden geübt

   Im Beruf

   Ein Notfallplan ist erst etwas wert, wenn er getestet wurde — dafür setze ich mich ein, auch wenn es Diskussionen kostet.

   Im Homelab

   Eine Änderung gilt erst als fertig, wenn sie live nachgewiesen funktioniert. Backups und Failover probiere ich aus, statt ihnen zu vertrauen.

4. 04 Änderungen brauchen einen Rückweg

   Im Beruf

   Patches und Changes laufen bei uns über Test, Freigabe und einen dokumentierten Rollback-Plan.

   Im Homelab

   Vor jedem Eingriff ein Snapshot oder Backup — und jede Änderung ist ein Git-Commit, der sich zurückdrehen lässt.

5. 05 Security von Anfang an

   Im Beruf

   Firewalls, Segmentierung, DMZ und SIEM sind bei mir Teil des Designs, nicht der Nacharbeit.

   Im Homelab

   Kein offener Port nach Hause, minimale Rechte pro Dienst, Secrets nur verschlüsselt.

6. 06 Ruhig bleiben, wenn es brennt

   Im Beruf

   Im Störfall erst Überblick, dann Priorität, dann Kommunikation — hektisch wird es von allein.

   Im Homelab

   Alarme kommen per Push; gelöste Probleme landen als Troubleshooting-Eintrag, damit sie nur einmal wehtun.