Private Cloud: Architekturentscheidungen — warum genau diese Software?

Diese Geschichte ist Teil der Serie “Private Cloud für alle”. Alle bisher erschienenen Teile findest du gesammelt auf lanforge.eu/posts/.

Im ersten Teil habe ich erklärt, warum ich mich auf den Weg zur eigenen Cloud gemacht habe. Heute geht es um die Frage, die sich direkt anschließt: Welche Software trägt das Ganze — und warum genau diese?

Ich werde bewusst nicht in technische Details abtauchen, das kommt in den folgenden Teilen. Hier geht es um die Entscheidungslogik: Was habe ich mir dabei gedacht, welche Alternativen habe ich verworfen, und welche Kompromisse habe ich bewusst eingegangen?

Eines vorweg: Dieses Setup habe ich für mich gebaut. Aber ich habe dabei immer im Hinterkopf behalten, dass dieselbe Architektur — mit etwas mehr Hardware — genauso für ein kleines Unternehmen funktionieren würde. Das beeinflusst viele der Entscheidungen, die ich gleich beschreibe.

Die Grundfrage: Warum nicht einfach einen fertigen Dienst mieten? #

Managed-Dienste sind bequem. Hetzner, IONOS, Nextcloud GmbH — alle bieten fertige Pakete an. Die Antwort ist nicht, dass diese Dienste schlecht wären. Die Antwort liegt in dem, was ich im ersten Teil beschrieben habe: Ich möchte wissen, wo meine Daten liegen, wer theoretisch Zugriff hat, und ich möchte nicht von den Geschäftsbedingungen eines einzigen Anbieters abhängig sein.

Wer eine eigene Infrastruktur betreibt, trägt mehr Verantwortung — aber gewinnt auch echte Kontrolle. Und genau das ist der Kern digitaler Souveränität.

Proxmox: Die Basis für alles andere #

Am Anfang steht Proxmox VE als Hypervisor. Es erlaubt mir, auf einem einzigen physischen Rechner mehrere voneinander isolierte virtuelle Maschinen zu betreiben. Warum Proxmox und nicht VMware oder Hyper-V? Weil Proxmox vollständig Open Source ist, keine Lizenzkosten hat — und weil VMware uns in den letzten Jahren eindrucksvoll gezeigt hat, wohin Abhängigkeit von proprietären Plattformen führen kann.

Kubernetes auf einem physischen Host: Klingt übertrieben — ist es aber nicht #

Auf Proxmox läuft ein vollständiger Kubernetes-Cluster: ein Control Plane Node, drei Worker Nodes und eine dedizierte NFS-VM — alles als isolierte virtuelle Maschinen auf demselben physischen Rechner. Wer jetzt denkt: “Kubernetes ist doch für große Umgebungen” — das stimmt in der Theorie, nicht in der Praxis.

Longhorn repliziert Volumes über alle drei Worker Nodes, KubeVIP stellt eine virtuelle IP als Static Pod bereit, Calico mit eBPF übernimmt das Pod-Netzwerk. Das System verhält sich intern genauso wie ein echtes Multi-Host-Cluster — weil es architektonisch auch eines ist.

Das ist eine bewusste Designentscheidung mit Blick auf die Zukunft: KubeVIP als Static Pod bedeutet, dass ein zweiter Control Plane Node einfach hinzugefügt werden kann, ohne die bestehende IP-Struktur anzufassen. Ein zweiter Proxmox-Host lässt sich als zusätzliche Worker Nodes einbinden — für Hardware-Ausfallsicherheit ohne Neuaufbau. Was heute auf einem einzigen Rechner läuft, kann morgen auf zwei oder drei Hosts verteilt werden. Nicht als Umbau, sondern als Erweiterung eines bereits dafür ausgelegten Systems.

Genau das macht diese Architektur auch für kleine Unternehmen interessant: Man fängt klein an, zahlt wenig, und wächst mit den Anforderungen — ohne irgendwann von vorne beginnen zu müssen.

Flux GitOps: Meine Infrastruktur lebt in einem Git-Repository #

Flux hält meinen Kubernetes-Cluster mit einem Git-Repository synchron. Jede Konfigurationsänderung — ob neue Anwendung, Update oder Einstellung — landet zuerst als Code in Git. Flux sorgt dann dafür, dass der Cluster diesen Zustand automatisch umsetzt.

Die Schicht darunter — die Server selbst — werden per Ansible ausgerollt. Das bedeutet: Von der leeren Maschine bis zum laufenden Dienst ist jeder Schritt dokumentiert und reproduzierbar. Ansible bringt das System in den definierten Ausgangszustand, Flux übernimmt dann die gesamte Applikationsschicht. Beide Werkzeuge zusammen ergeben ein vollständiges Bild: Keine manuelle Konfiguration die irgendwo in Vergessenheit gerät, kein “das hab ich damals irgendwie hingebogen” — sondern Infrastruktur die man versteht, nachvollziehen kann, und im Notfall schnell wiederherstellen kann.

Wenn morgen der Rechner abbrennt und ich neue Hardware habe, ist die Wiederherstellung kein tagelanger Fummelkram — sondern ein definierter, weitgehend automatisierbarer Prozess. Das ist kein Luxus, das ist gutes Handwerk.

Forgejo: Der nächste Schritt in Richtung vollständiger Unabhängigkeit #

Das GitOps-Repository, das Flux überwacht, liegt aktuell noch als privates Repository bei GitLab. Das ist bewusst so — und hat einen konkreten Grund: Ein selbstgehostetes Git-System setzt voraus, dass der Cluster bereits läuft. Wer sein Deployment-Repository auf demselben Cluster hostet, den es deployen soll, hat ein klassisches Henne-Ei-Problem. Für den initialen Aufbau braucht es einen externen Anker.

Forgejo teste ich deshalb als langfristige Alternative — insbesondere im Hinblick auf die integrierten Forgejo Actions, die CI/CD-Pipelines ohne externe Dienste wie GitHub Actions ermöglichen. Wenn Actions und das Gesamtpaket ausreichen, ist der Plan: Das externe Repository wandert zu Codeberg — einem deutschen, gemeinnützigen Forgejo-Dienst in Berlin — als öffentlich abgesicherter Spiegel. Intern übernimmt dann die selbstgehostete Forgejo-Instanz alles, was im laufenden Cluster gebraucht wird.

Das ist kein rein technisches Experiment, sondern ein konsequenter nächster Schritt: Wer Code, Konfiguration und Deployments vollständig unter eigener Kontrolle hat, ist nicht mehr darauf angewiesen, dass amerikanische Plattformen diese Prozesse zuverlässig und datenschutzkonform abwickeln.

Longhorn, Contabo S3 und SeaweedFS: Storage und Backups #

Longhorn übernimmt die Speicherverwaltung innerhalb des Clusters. Es sorgt dafür, dass Anwendungsdaten persistent gespeichert werden, erstellt automatisch Snapshots und kann Volumes direkt in externen S3-Speicher sichern.

Dieser externe Speicher liegt bei Contabo in München — deutsches Rechenzentrum, deutsches Unternehmen, DSGVO-konform. S3 ist dabei kein AWS-Produkt, sondern ein offenes Protokoll. Ich könnte den Anbieter morgen wechseln, ohne meine Backup-Logik anfassen zu müssen. Genau diese Anbieterunabhängigkeit war mir wichtig.

Ein Detail das hier direkt dazugehört: Nextcloud speichert seine Dateien nicht lokal im Cluster, sondern direkt im S3-Bucket bei Contabo. Der Cluster hält nur die Datenbank — Metadaten, Freigaben, Kalendereinträge. Die eigentlichen Dateien liegen bereits in S3 und brauchen deshalb kein separates Backup. Das vereinfacht die Backup-Strategie erheblich und ist gleichzeitig der Grund, warum ein Restore von Nextcloud schnell und sauber funktioniert.

Wer noch einen Schritt weiter gehen will: SeaweedFS ist eine selbsthostbare, S3-kompatible Objektspeicherlösung, die direkt im Cluster betrieben werden kann. Als alternativer Restore-Target für Velero lässt sie sich nahtlos einbinden und ermöglicht es, auch den Backup-Speicher vollständig unter eigener Kontrolle zu halten — ohne externe Anbieter. Für mein Setup ist Contabo S3 die pragmatische Standardlösung; SeaweedFS steht als Option bereit, wenn noch mehr Unabhängigkeit gewünscht ist.

Traefik: Der unsichtbare Türsteher #

Traefik ist der Reverse Proxy, der eingehende Anfragen an die richtigen Dienste weiterleitet. Für den Nutzer unsichtbar — für den Betrieb unverzichtbar.

Was Traefik bei mir explizit nicht tut: Zertifikate beantragen. Das ist Aufgabe von cert-manager, der vollständig eigenständig arbeitet. Traefik konsumiert die fertigen Zertifikate nur — es liest sie aus Kubernetes Secrets, die cert-manager befüllt.

Das Zusammenspiel funktioniert so: cert-manager kennt zwei ClusterIssuer — einen für Let’s Encrypt Staging und einen für Produktion. Neue Dienste bekommen zunächst ein Staging-Zertifikat, das funktional identisch ist, aber von Browsern nicht als vertrauenswürdig angezeigt wird. Erst wenn alles korrekt läuft, wird im Certificate-Objekt ein einziger Wert geändert — der Issuer von letsencrypt-staging auf letsencrypt-prod. cert-manager erkennt die Änderung, beantragt das echte Zertifikat, und Traefik nutzt es ab diesem Moment automatisch. Kein Neustart, kein manueller Eingriff.

Dieser Zwei-Stufen-Ansatz hat einen konkreten Grund: Let’s Encrypt hat strikte Rate Limits für Produktionszertifikate. Wer beim Einrichten eines neuen Dienstes zu viele Fehlversuche produziert, wird für Stunden gesperrt. Mit einem Staging-Issuer testet man den kompletten Ablauf ohne dieses Risiko.

Kanidm: Ein Login für alles — und warum das wichtiger ist als es klingt #

Kanidm ist meine Identity-Management-Lösung — das zentrale Benutzerverwaltungssystem meiner privaten Cloud. Und es ist vielleicht die Entscheidung, über die ich am längsten nachgedacht habe.

Das Problem das Kanidm löst, ist eines das viele Self-Hosting-Setups unordentlich macht: Jede Anwendung hat eigene Nutzerkonten, eigene Passwörter, kein zentrales Management. Man vergisst Accounts, hat inkonsistente Passwortregeln, und wenn jemand ausscheidet — im Unternehmenskontext ein echtes Problem — muss man sich durch ein Dutzend Anwendungen klicken.

Kanidm stellt Single Sign-On bereit: Ein Konto, ein Passwort, Zugriff auf alle Dienste. Nextcloud, Paperless, Immich, Forgejo — alle authentifizieren sich gegen Kanidm. Dazu kommt ein sauberes Gruppenkonzept: Ich kann definieren, wer Zugriff auf welche Dienste hat, und das zentral verwalten. Für mich als Einzelperson ist das Komfort. Für ein kleines Unternehmen mit fünf, zehn oder zwanzig Mitarbeitenden ist das der Unterschied zwischen einer kontrollierbaren IT und einem Flickenteppich aus Einzellösungen.

Warum Kanidm und nicht das bekanntere Keycloak? Kanidm ist schlanker, moderner gebaut, und deutlich einfacher zu betreiben — ohne auf die wesentlichen Features zu verzichten. Für dieses Setup ist das der richtige Trade-off.

Die Anwendungen: Was ich damit ersetze #

Auf dieser Infrastruktur laufen heute folgende Dienste produktiv:

Nextcloud ersetzt iCloud für Dateisynchronisation, Kalender und Kontakte. Mit der integrierten Nextcloud Office Collaboration Suite bearbeite ich Dokumente direkt im Browser — dieser Artikel entstand darin. Was Nextcloud nicht ist: ein Kompromiss. Es ist eine ausgereifte, aktiv entwickelte Plattform, die in Unternehmen weltweit im Einsatz ist.

Immich ersetzt Google Photos. Automatisches Backup vom Smartphone, Alben, Suche — mit dem entscheidenden Unterschied, dass meine Fotos nie mein System verlassen. Gerade Fotos sind der persönlichste Datenschatz, den die meisten Menschen bedenkenlos bei Apple oder Google lagern.

Als Alternative läuft parallel auch Nextcloud Memories — eine direkt in Nextcloud integrierte Fotoverwaltung, die keinen zusätzlichen Dienst erfordert. Der Vorteil: weniger Komplexität, alles unter einem Dach. In der täglichen Nutzung überzeugt mich bisher Immich mehr — die Oberfläche ist durchdachter, die mobile App schneller, die Suche besser. Aber ich teste beide bewusst weiter, bevor ich eine endgültige Entscheidung treffe.

Vaultwarden ist mein Passwortmanager, kompatibel mit allen Bitwarden-Clients. Passwörter gehören zu den sensibelsten Daten überhaupt — sie auf einem fremden Server zu lagern war für mich immer ein ungutes Gefühl.

Paperless-ngx verwaltet meine gesamten digitalen Dokumente. Alles landet dort als durchsuchbares, strukturiertes Archiv — kein physisches Papierchaos mehr, und keine Dokumente in irgendwelchen Cloud-Ordnern, die ich irgendwann vergesse.

Monitoring: Wissen was passiert #

Eine Infrastruktur zu betreiben, ohne zu wissen was darin vorgeht, ist kein Betrieb — das ist Hoffnung. Deshalb läuft ein vollständiger Observability-Stack: Prometheus sammelt Metriken, Loki aggregiert Logs, Alloy übernimmt die Datensammlung, und Grafana macht alles sichtbar. Das ist die tiefe Schicht — sie beantwortet Fragen wie “Warum ist der Pod um 3 Uhr nachts neu gestartet?” oder “Wie entwickelt sich der Speicherverbrauch über die letzten 30 Tage?”.

Daneben läuft Gatus — und das ist bewusst eine andere Kategorie. Gatus prüft kontinuierlich ob meine Dienste von außen erreichbar sind und zeigt das Ergebnis als übersichtliche Statuspage. Keine Dashboards, keine Queries, kein Eintauchen in Metriken. Ein Blick genügt um zu wissen: Nextcloud läuft, Vaultwarden läuft, Immich hat gerade ein Problem. Gerade für den Alltag ist das unbezahlbar — weil man nicht immer Grafana öffnen will, wenn man nur wissen möchte ob alles in Ordnung ist. Für ein Unternehmen hat das noch einen weiteren Vorteil: Die Statuspage lässt sich intern teilen, damit auch Nutzer ohne Zugang zum Monitoring-Stack auf einen Blick sehen ob ein Dienst gerade gestört ist.

Das klingt nach Aufwand. In der Praxis läuft das alles automatisiert im Hintergrund. Der Aufwand war die Einrichtung — der Betrieb ist wartungsarm. Und für ein Unternehmen ist ein solcher Stack kein Nice-to-have, sondern die Grundlage für verlässlichen Betrieb.

Was steckt hinter diesen Entscheidungen? #

Jede Entscheidung in diesem Setup folgt denselben Kriterien: Open Source, datenschutzkonform, und so gebaut, dass kein einzelner Anbieter zum Flaschenhals werden kann. Dazu kommt ein Kriterium, das mir persönlich wichtig ist: Das System muss im Ernstfall schnell und sauber wiederherstellbar sein — nicht nur im Normalbetrieb funktionieren.

Genau diese Denkweise bringe ich auch in Kundenprojekte ein. Nicht jedes Unternehmen braucht Kubernetes — aber jedes Unternehmen profitiert davon, seine IT-Entscheidungen mit der gleichen Logik zu treffen: Was kontrolliere ich wirklich? Was passiert, wenn Anbieter X morgen die Preise verdoppelt oder den Dienst einstellt? Kann ich meine Infrastruktur im Notfall in vertretbarer Zeit wiederherstellen?

Wenn Sie sich fragen, wie eine solche Architektur — skaliert auf Ihre Anforderungen — für Ihr Unternehmen aussehen könnte, sprechen Sie mich gerne an.

Im nächsten Teil: Es wird konkret. Hardware, tatsächliche Kosten meines Home-Lab-Setups, und der erste Blick auf das reale Setup.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen — ich freue mich auf die Diskussion: