Private Cloud: Die Applikationsschicht — welche Apps laufen und warum

Nextcloud, Paperless-ngx, Immich, Vaultwarden — die eigentliche Motivation #

Wenn man ehrlich ist, baut man diesen ganzen Cluster nicht wegen Calico oder Flux CD. Man baut ihn, weil man seine Dateien selbst hosten, seine Fotos nicht in eine fremde Cloud hochladen und seine Dokumente nicht auf den Servern irgendeines Unternehmens wissen will. Die vier Applikationen in diesem Post sind der eigentliche Grund für alles, was im vorherigen Teil beschrieben wurde.

Trotzdem lohnt es sich, genau hinzuschauen: Welche Apps laufen hier, warum diese und nicht andere, und welche bewussten Entscheidungen stecken hinter der Art und Weise, wie sie deployt sind?

Die vier Apps — und was sie leisten #

Nextcloud ist die zentrale Ablage: Dateien, Kalender, Kontakte, Notizen. Es ist das, was für die meisten Menschen “die Cloud” bedeutet — nur dass sie eben auf dem eigenen Server läuft. Nextcloud ist nicht das schmalste Tool, aber es ist das vollständigste für diesen Anwendungsfall.

Paperless-ngx nimmt eingehende Dokumente — gescannte Briefe, PDFs, Rechnungen — und macht sie durchsuchbar. Wer einmal alle Dokumente der letzten Jahre indiziert hat, will nie wieder in Ordnern suchen. Das Tool ist unspektakulär und tut genau das, was es soll.

Immich ist der Ersatz für Cloud-Fotodienste. Automatischer Upload vom Smartphone, Gesichtserkennung, Alben — und die Fotos bleiben auf dem eigenen Server. Immich ist das jüngste Projekt in diesem Stack und hat sich in kurzer Zeit enorm entwickelt.

Vaultwarden ist eine ressourcenschlanke, kompatible Reimplementierung eines bekannten Passwortmanagers. Passwörter lokal zu hosten ist eine Grundsatzentscheidung: Wer dem eigenen Server nicht traut, sollte diesen Weg nicht gehen. Wer es tut, bekommt volle Kontrolle über die eigenen Zugangsdaten.

Eigene StatefulSets statt Bitnami-Subcharts #

Alle vier Applikationen benötigen eine Datenbank — entweder PostgreSQL, Redis oder beides. Eine naheliegende Option wäre es, die Datenbanken als Subcharts der jeweiligen Helm-Charts mitzuziehen, wie es etwa Bitnami-Charts standardmäßig anbieten. Ich habe mich dagegen entschieden — und zwar aus einem konkreten Grund: Abhängigkeiten von Drittanbieter-Charts bedeuten, dass Updates, Breaking Changes und Deprecations außerhalb der eigenen Kontrolle liegen.

Stattdessen läuft jede Datenbank als eigenes StatefulSet mit eigenem Deployment — direkt in Kubernetes, ohne externe Chart-Abhängigkeit. Das ist mehr initiale Konfigurationsarbeit, aber das Ergebnis ist ein Stack, bei dem jede Komponente verstanden und kontrolliert ist. Wer weiß, wie sein PostgreSQL deployt ist, weiß auch, wie er es sichert, migriert oder ersetzt.

Warum kein CNPG-Operator? #

Der CloudNativePG-Operator ist eine elegante Lösung für PostgreSQL in Kubernetes: automatische Replikation, Failover, Point-in-Time-Recovery direkt aus dem Operator heraus. Auf dem Papier klingt das überzeugend.

In der Praxis hat CNPG für diesen Anwendungsfall einen entscheidenden Nachteil: Die Backup-Strategie wird komplexer. CNPG bringt eine eigene Backup-Abstraktion mit, die sich nicht ohne weiteres mit dem restlichen Velero-basierten Backup-Workflow integriert. Man landet entweder bei zwei parallelen Backup-Mechanismen — was Fehlerquellen verdoppelt — oder man gibt die Kontrolle über den Backup-Prozess an den Operator ab, was der Philosophie dieses Setups widerspricht.

Die Entscheidung war also keine gegen CNPG als Technologie, sondern für ein einheitliches, verstandenes Backup-Konzept. Dazu mehr im nächsten Post.

App-Abhängigkeiten auf einen Blick #

Die folgende Grafik zeigt, welche App auf welche Datenbank und welchen Storage angewiesen ist — und welche drei der vier Apps über Kanidm SSO angebunden sind:

Ein Detail fällt dabei sofort auf: Vaultwarden hat zwar eine eigene Datenbank, aber keine SSO-Anbindung. Das ist keine Lücke — es ist eine bewusste Entscheidung. Der Passwortmanager soll bewusst unabhängig vom SSO-System bleiben: Wenn Kanidm aus irgendeinem Grund nicht erreichbar ist, muss der Zugang zu Passwörtern trotzdem funktionieren. Wer seinen Schlüsselbund hinter dem Schloss einschließt, das er gerade öffnen will, hat ein Problem.

Kanidm und SSO — aber nur wo es sinnvoll ist #

Nextcloud, Paperless-ngx und Immich sind alle drei an Kanidm als Single-Sign-On-Provider angebunden. Das bedeutet: ein Login, drei Apps — und die Benutzerverwaltung läuft zentral. Das ist komfortabel für den Alltag und reduziert die Angriffsfläche, weil keine Passwörter direkt in den Apps gespeichert werden.

Mehr zu Kanidm selbst — warum ich es gegenüber anderen Lösungen bevorzuge und wann es die falsche Wahl wäre — kommt in einem späteren Post.

Wie eine Anfrage durch den Stack fließt #

Vom Browser bis zur Datenbank durchläuft jede Anfrage mehrere Schichten. Das folgende Diagramm zeigt diesen Weg am Beispiel einer Nextcloud-Anfrage:

Der Weg ist in jedem Fall derselbe: HTTPS rein, Traefik entscheidet wohin, Kanidm prüft die Session, der App-Pod verarbeitet die Anfrage, PostgreSQL speichert Metadaten auf Longhorn, und Dateien landen direkt im NFS-Volume. Jede dieser Schichten ist im vorherigen Post beschrieben — hier kommen sie zusammen.

Fazit: Der Stack ist kein Zufall #

Die Applikationen in diesem Post sind nicht zufällig zusammengewürfelt. Sie decken die wichtigsten Alltagsanwendungsfälle ab — Dateien, Dokumente, Fotos, Passwörter — und sie sind so deployt, dass Backup, Updates und Betrieb verstanden und kontrollierbar bleiben. Eigene StatefulSets statt Drittanbieter-Subcharts, kein CNPG-Operator zugunsten eines einheitlichen Backup-Konzepts, SSO nur wo es sinnvoll ist.

Im nächsten Post geht es genau darum: wie der Backup-Stack aufgebaut ist, was gesichert wird — und was bewusst nicht.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen mit digitaler Souveränität — ich freue mich auf die Diskussion: