Selfhosted Setup 2025: Mein neuer Workflow mit Proxmox, Komodo und GitOps

Diejenigen die ein Homelab auch zum experimentieren und lernen nutzen, kennen das Problem: Nichts ist richtig und irgendwie machen alle anderen alles immer besser, schöner, toller. Naja, zumindest mir gehts häufig so wenn ich Blogbeiträge oder Posts in r/homelab lese. Eine längere Zeit nutzte ich Kubernetes für mein Homelab und habe damit einige Dinge gelernt. Die Umgebung hat auch Spaß gemacht, wurde mir aber irgendwann zu anstrengend zu administrieren. Ich setze Kubernetes nicht in meinem normalen Berufsleben ein, sodass mir häufig die Übung fehlt. Und daheim: Nunja, ist ja eher ein Homeprod als ein Homelab. Was ich in der ganzen Zeit aber super fand ist das GitOps Prinzip. Es machte die Pflege von Versionen einfach ohne mal wieder in einen riesen breaking change gelaufen zu sein der “alles kaputt macht”.

GitOps ist ein Ansatz, bei dem Git als Single Source of Truth für die gesamte Infrastruktur- und Anwendungs­konfiguration dient. Änderungen werden über Pull Requests versioniert und automatisiert von CI/CD-Pipelines oder Deploy-Operatoren (z. B. Argo CD, Flux) in die Zielumgebungen übernommen. Dadurch werden Deployments reproduzierbarer, auditierbarer und leichter automatisierbar. GitOps fördert zudem konsistente Workflows, die sowohl für Entwickler als auch für Operations-Teams gut nachvollziehbar sind.

Mein Homelab sah also nach dem Weggang von Kubernetes so aus, dass ich diverse VMs für Docker Container hatte und divere LXC für einzelne Anwendungen. Ich hatte die meisten Container mittels :latest Tag versehen um mich so nicht mehr um die Updates großartig kümmern zu müssen. Watchtower hat sich dann um die Updates entsprechend gekümmert. Bei größeren Tools, oder denen häufiger ein breaking change enthalten ist, wie z. B. bei Immich, habe ich die Version gepinnt. Bekomme so aber nicht mehr mit wann ein neues Update erschienen ist. Zumindest nicht, wenn die Software nicht in ihrer Weboberfläche einen erinnert.

Als ich dann vor einiger Zeit auf Komodo aufmerksam gemacht wurde, haben sich meine Gedanken über mehrere Tage hinweg damit beschäftigt wie ich die Software gut in mein Homelab einbauen kann. Komodo ermöglicht nämlich das GitOps Prinzip bei Docker bzw. Docker Compose Umgebungen.

Das Grundprinzip meines Homelabs

Nachdem ich mir ein paar Blog Beiträge (z. B. den hier) und YouTube Videos (z. B. das hier) zu Komodo angeguckt habe, war mir klar, dass ich meine Docker Installationen damit verwalten werde. Gerade der Blog Post von Nick hat mich auch dazu gebracht wie das ganze im “Backend” ggf. aussehen könnte.

Der Stromverbrauch meines Homelabs hatte sich die ganzen Monate immer so zwischen 120 W und 150 W bewegt. Nichts tragisches für mich, aber ggf wäre auch eine Reduzierung möglich. Zudem hatte ich die ganze Zeit sämtliche Dinge immer auf meinen Unraid Server gesichert. Das wollte ich auch ändern. Ziel war es also alles auf einen Proxmox Host, anstatt vorher drei Kubernetes Nodes, zu bringen. Dazu sollte der Proxmox Backup Server als dedizierte Maschine mit eigenem Stroage bereit stehen. Die NFS implementierung von Unraid ist einfach extrem nervig.

Des weiteren wollte ich nicht mehr duzende virtuelle Maschinen oder LXC auf dem System am laufen haben, es soll alles etwas verschlankt werden. Allerdings bin und war ich nie ein Fan davon alles in eine VM zu quetschen. Aber das muss jeder für sich selbst entscheiden.

Wie sieht mein Homelab jetzt aus?

Mittlerweile habe ich nur zwei Thin Clients am laufen: Einen als Proxmox Host und einen als Proxmox Backup Server. Natürlich mein Unraid NAS noch zusätzlich. Aber auf dem Proxmox Server läuft jetzt alles. Der ist zwar sehr gut ausgelastet, wird aber in der nächsten Zeit noch durch einen Minisforum MS-01 ersetzt. Das hat den Vorteil, dass ich den PVE dann auch via 10 GBit anschließen kann. Perspektivisch würde ich nämlich gerne das Netzwerk etwas aufrüsten.

Die Fragmentierung meiner virtuellen Systeme hat auch stark nachgelassen. Auch wenn es noch etwas mehr sind als geplant. Manche Systeme lassen sich einfach schwer containerisieren bzw. möchte ich auf Grund von Hardwareressourcennutzung separieren. Im Grundlegenden habe ich vier wichtige virtuelle Maschinen:

  1. infra01 - Für Infrastruktur relevante Systeme
  2. docker01 - Für meine ganzen “normalen” Anwendungen
  3. media01 - Für alle Anwendungen rund um Bewegbild
  4. ha01 - Home Assistant

Screenshot meines Proxmox Servers

Dazu gesellen sich noch zwei AdguardHome LXC, meine LXC für die Wetterstation und Wetter Webseite sowie Nextcloud (zieht aber auch bald um). Gehen wir mal auf die einzelnen Systeme ein.

infra01 - Das Backend meine Homelabs

Als so ziemlich wichtigste virtuelle Maschine der neuen Infastruktur ist diese VM quasi das Herzstück des ganzen. Hier werden alle relevanten Anwendungen gehostet. Diese Maschine ist aber leider auch gewisser single point of failure. Dadurch das ich kein Cluster mehr betreibe, würde sich der Punkt sonst einfach nur verschieben. Da wir später noch auf den genauen Workflow eingehen werden liste ich euch nur die dortigen Anwendunge einmal auf:

docker01 - Anwendungen des täglichen Bedarfs

Auf dieser VM lasse ich so ziemlich alle Anwendungen laufen die nicht auf die beiden anderen Systeme gehören. Gegebenenfalls wird hier zu einem späteren Zeitpunkt noch mal eine zweite VM hinzu kommen um die Apps ein wenig zu verteilen. Schlussendlich laufen hier die Apps die ich in meiner Top 10 schon verbloggt habe. Zusätlich aber auch Dinge wie

media01 - Für das Bewegbild

Alle Anwendungen rund um Filme und Serien, bis auf Jellyfin finden sich hier. Jellyfin hat seinen eigenen LXC bekommen um besser auf die iGPU des Hostsystems zugreifen zu können. Zwar sind 99 % aller Medienwiedergaben DirectPlay, aber man weiß ja nie.

Mein Workflow

Schlussendlich ist es bis hier hier nicht so wirklich spannend. Einfach nur wie ich die diversen Anwendungen auf diverse virtuelle System aufteile. Spannender wird es aber mit dem eigentlichen Workflow, denn der nutzt wieder das GitOps Prinzip. Da Komodo leider keine verschlüsselten Secrets kann, wollte ich meine compose Dateien nicht mehr auf GitHub hosten, sondern auf meinem eigenen GIT Server. Für diese Zwecke nutze ich schon immer gitea, auch wenn es da mittlerweile diverse Alternativen gibt.

Ich habe also zwei Repositories auf meinem Git Server erstellt, einen für den docker01 als “apps-stack” sowie für den media01 als “media-stack”. Das sind 08-15 compose Dateien ohne weiteren besonderen Konfigurationen. Sobald ich Änderungen pushe wird ein Webhook zu Komodo gesendet. Dieser triggert dort einen Workflow um das Repo zu aktuallisieren und die Änderungen entsprechend auf dem Zielsystem zu deployen. Ich kann über diesen Weg auch dedizierte Konfigurationsdateien mitgeben die einzelne Anwendungen benötigen. So habe ich alles immer zusammen in einem Repo. Dieses Vorgehen gilt, wie geschrieben, für die den docker01 sowie für den media01. Die Anwendungen auf dem infra01 werden so nicht deployed. Gitea installieren zu können ohne ihn zu haben funktioniert nunmal nicht. Sobald Komodo verschlüsselte Secrets beherrscht würde ich die Dateien sicherlich wieder auf GitHub auslagern um direkt mit dem Deployment starten zu können.

Update Management der Container

In meinen Compose Dateien versuche ich Container zu verwenden deren Entwickler semver verwendet. Damit habe ich es einfacher die Container leichter zu updaten. Okay, eigentlich habe ICH es nicht einfacher, sondern Renovate. Renovate habe ich auch bereits in meinem Kubernetes Cluster verwendet, damals als SaaS jetzt auch selfhosted. Renovate läuft alle vier Stunden per cronjob und überprüft ob es in den angebenen Container Registry eine neuere Version gibt. Sobald das der Fall ist, erstellt mir der Service einen Pull Request in dem jeweilgen Repository. Diesen kann ich dann entsprechend aktzeptieren und der o. a. Workflow wird getriggert.

gitea pull request beispiel

Sollte eine Anwendung extrem häufig eine neue Version veröffentlichen, kann ich natürlich auch ein automatisches commit erstellen, dann muss ich nicht mehr händisch eingreifen. Auf der anderen Seite kann z. B. Postgres bei Upgrades auf neue Versionen unschön werden. Derzeit wird es noch nicht unterstützt, dass die Datenbank einfach auf die neue Version gehoben wird, wie das bei MySQL oder MariaDB der Fall ist. Entsprechend schließe ich die Postgres Container von Renovate aus und belasse sie derzeit auf Version 17.

Backup und Restore

Im vorherigen Proxmox Cluster habe ich Unraid als NFS Storage eingebunden und darauf meine Backups gespeichert. Auch mit dem Proxmox Backup Server als virtuelle Maschine hatte ich eine Zeit lang dieses Vorgehen. Wie du Unraid NFS Shares als Ziel im Proxmox Backup Server einbindest, kannst du in diesem Beitrag lesen.

Weiter oben habe ich bereits erwähnt, dass ich nun einen dedizierten PBS einsetze. Dieser ist mit einer 1 TB großen SSD ausgestattet auf dem ich meine Backups speichere. Zuküftig möchte ich noch ein Backupsatz außer Haus speichern, weil ich sonst das 3-2-1-Prinzip nicht einhalten kann und mir das schon wichtig ist.

Das 3-2-1-Backup-Prinzip beschreibt eine einfache Strategie, um Daten zuverlässig zu schützen. Dabei existieren 3 Kopien der Daten, gespeichert auf 2 unterschiedlichen Medien, wobei 1 Kopie extern (z. B. Offsite oder in der Cloud) aufbewahrt wird. Dieses Vorgehen reduziert das Risiko von Datenverlust durch Hardwarefehler, menschliche Fehler oder Katastrophen erheblich. Es gilt als bewährter Standard für sichere und robuste Backup-Konzepte.

Fazit

Das Setup läuft jetzt noch nicht so lange, fühlt sich für mich aber stabiler und kompletter an. Zudem habe ich die Updates der Anwendungen wieder besser im Griff. Allerdings muss ich mich noch um die Updates für die Betriebssysteme kümmern. Dazu werde ich mir sicherlich ein Ansible Playbook schreiben dass das für mich vereinfachen wird. Solltest du Fragen oder Anregungen zu irgendwelchen Punkten haben, kontaktiere mich einfach über die Wege oben in der Menüleiste.