Es gibt diesen einen Moment, den jeder Self-Hoster kennt: Man starrt auf das Dashboard seines Smartphones oder den Desktop und fragt sich: „Warum fühlt sich das eigentlich so schwerfällig an?"

Jahrelang war Nextcloud der unangefochtene König in meinem Homelab. Es war die eierlegende Wollmilchsau, der digitale Schweizer Offiziersmesser-Ersatz für alles. Und das war gut. Ich persönlich schätze Frank Karlitschek sehr, er ist einer der essentiellen Treiber von Open Source und digitaler Souveränität. Aber seien wir ehrlich: Im Jahr 2026 fühlten sich Nextcloud-Updates oft an wie russisches Roulette – nur dass die Kugel meistens den Desktop-Client, die PHP-Performance oder die Datenbank-Indizes traf. Wenn die Familie am Sonntagabend fragt, warum die Urlaubsfotos nicht laden, und man selbst erst einmal mühsam per SSH occ maintenance:mode --off tippen muss, weiß man: Es ist Zeit für eine radikale Veränderung.

Heute hat sich etwas geändert. Ein neues, schlichtes Icon ziert meinen Screen. Es heißt OpenCloud. Und seit dem Umzug auf meinen K3s-Cluster läuft nicht nur die Synchronisation flüssiger, sondern ich habe auch das Gefühl, endlich wieder die volle Kontrolle über meine Infrastruktur zu haben.

Der Frust-Faktor: Warum der Wechsel 2026 überfällig war

Versteht mich nicht falsch: Nextcloud hat Großartiges für die Open-Source-Welt getan. Aber die Architektur aus den 2010er Jahren wie PHP-Basis, Apache/Nginx und eine schwere SQL-Datenbank, stößt in einer modernen Container-Welt an Grenzen. Ich wollte einen Cloud-Speicher, keine Wetterstation mit integriertem Kanban-Board, das meine CPU auf 100 % jagt, nur weil im Hintergrund ein Thumbnail generiert wird.

Die drei Kandidaten im Check (Stand März 2026)

Bevor ich den Stecker zog, habe ich mir die Landschaft genau angeschaut:

1. Nextcloud: Der bekannte Alleskönner. Aber der „Feature-Bloat" ist real. Für jede neue Funktion scheint die Stabilität der Kernfunktionen (Dateisynchronisation) ein Stück weit zu leiden.
2. ownCloud Infinite Scale (oCIS): Der technologische Quantensprung. In Go geschrieben, keine Datenbank mehr nötig. Aber nach der Übernahme durch Kiteworks (2023/24) herrschte Unruhe. Der Fokus verschob sich spürbar Richtung Enterprise, die Community-Interessen fühlten sich zweitrangig an.
3. OpenCloud: Hier kommt der "sympathische Rebell" ins Spiel. OpenCloud ist ein eigenständiger Fork von oCIS, massiv vorangetrieben vom Team hinter Heinlein Support (mailbox.org). Das Ziel: Ein schlankes, stabiles System für digitale Souveränität, ohne den Ballast von US-Risikokapital.

Der „Battle of Resources": Nextcloud vs. OpenCloud

Ressourcen-Vergleich im Leerlauf (Idle)

Während Nextcloud ständig im Hintergrund mit Datenbank-Abfragen und PHP-Prozessen beschäftigt war, „schläft" OpenCloud förmlich, wenn niemand zugreift. Sobald ich aber eine Datei hochlade, schlägt die Go-Performance voll zu.

Warum OpenCloud mein Herz (und meine CPU) erobert hat

1. Die DNA von Heinlein

Wenn die Leute hinter mailbox.org, die seit 30 Jahren gegen massive Widerstände für datenschutzkonforme Lösungen in Deutschland kämpfen, einen Fork machen, dann ist das ein Statement. Hier geht es nicht um den nächsten Exit, sondern um Infrastruktur, der man vertrauen kann.

2. Der „No-Database"-Zen-Modus

OpenCloud braucht keine PostgreSQL oder MariaDB. Die Metadaten liegen direkt im Dateisystem bei den Daten selbst. Wo keine Datenbank ist, kann auch kein Datenbank-Index kaputtgehen. Und wer schon mal eine Nextcloud-Instanz nicht updaten konnte, weil die installierte MariaDB-Version zu alt war, weiß, welchen Schmerz ich meine.

2. Eleganz als Architekurentscheidung

Overengineering ist die stille Pest jeder selbst Infrastruktur. Wer keine Datenbank braucht, baut keine ein. Wer keinen separaten Cache-Layer braucht, betreibt keinen. OpenCloud macht vor, wie elegante Softwarearchitektur aussieht: so wenig Komplexität wie möglich, so viel Funktionalität wie nötig. Das ist keine Faulheit, das ist Developer-Ingenieurskunst.

Deep Dive: Das Setup auf K3s

Ich betreibe OpenCloud auf meinem Cluster namens Caliban. Das Herzstück ist das Container-Image opencloudeu/opencloud-rolling:latest mit diesem pragmatischen Init-Befehl:

bash

command: ["sh", "-c", "opencloud init || true; opencloud server"]

Das || true ist lebenswichtig: OpenCloud generiert beim ersten Start zufällige Passwörter und Secrets. Bei jedem weiteren Neustart würde init fehlschlagen, da die Config bereits existiert. Ohne || true landet der Pod in einem hässlichen CrashLoopBackOff.

Die Netzwerk-Magie und die HTTPS-Falle

Damit das hinter Traefik und Cloudflare funktioniert, zwei kritische Einstellungen:

1. PROXY_TLS=false – OpenCloud verwendet intern kein eigenes TLS.
2. X-Forwarded-Proto: https – Eine Traefik-Middleware erzwingt diesen Header. Ohne ihn schickt OpenCloud den Browser in eine endlose Redirect-Schleife.

Die ZFS-Backup-Strategie: Schlafen statt Dumpen

Früher: Datenbank-Dump, Dateien sichern, hoffen dass beide Stände zeitlich passen. Heute:

bash

zfs snapshot tank/k3s/pvc-opencloud-data@backup_$(date +%Y-%m-%d)
zfs send tank/k3s/pvc-opencloud-data@backup_$(date +%Y-%m-%d) | ssh backup-server zfs recv storage/cloud-backup

Da alle Metadaten direkt im PVC liegen, ist dieser Snapshot atomar konsistent. Stand von vor zwei Tagen mounten, OpenCloud startet exakt so, als wäre nichts gewesen. Keine DB-Inkonsistenzen mehr. Das ist wahre Freiheit für Admins.

Die Mobile-Erfahrung: Warum die native App den Sack zumacht

1. Geschwindigkeit: Wo die Nextcloud-App den „Lade-Kreisel" drehte, ist die OpenCloud-App sofort da. Die Go-Basis macht sich massiv bemerkbar.

2. Stabilität des Syncs: Foto-Upload läuft felsenfest. „Set and forget" – endlich. Ich habs probiert, es läuft bei mir perfekt, auch wenn mein primärer Foto-Dienst ein lokaler Immich-Service ist.

3. Files On-Demand: Die gesamte Verzeichnisstruktur sichtbar, ohne den Handyspeicher zu fluten. Erst beim Öffnen wird geladen.

4. Souveränität bis in die Hosentasche: Biometrische Auth, direkt von der OpenCloud GmbH Berlin. Vom Server im Keller bis zur App in der Tasche. Alles DSGVO-konform aus einer Hand. Und die Verantwortung dafür trage nur ich.

5. Fokus statt Feature-Monster: Eine App, die eine Sache richtig macht.

Bonus: OpenCloud als sovereign Ebook-Bibliothek

Es gibt einen Use Case, den ich beim Schreiben dieses Artikels für mich selbst entdeckt habe. Und der mich fast mehr begeistert als der reine Dateisync.

Wer sich von Amazons Walled Garden verabschieden will, denkt zuerst an Musik, Filme und Serien. Die Lesekultur war mir mit meinem Kindle immer ein Dorn im Auge, aber die Lösung wurde mir erst klar als vorgestern als mein Boox Go 7 ankam – ein Android-basierter E-Ink-Reader, der statt eines Kindle-Ökosystems ein offenes Android-System mitbringt.

Das Problem mit Kindle (und warum es kein technisches ist)

Amazon weiß sehr genau, was du liest, wann du liest, wie schnell du liest, und wo du aufgehört hast. Das ist kein Versehen, das ist Produktstrategie. Wer ein Kindle-Buch kauft, kauft eigentlich eine Lizenz, die jederzeit entzogen werden kann und auch wird. Das ist keine Paranoia, das ist AGB.

Die Lösung: DRM-freie EPUBs, selbst gehostet, auf einem offenen Gerät. Klingt nach viel Bastelei, viel Arbeit. Ist es aber in meinem Szenario gar nicht.

Der Setup: OpenCloud als Ebook-Server

Da OpenCloud bereits läuft und einen /ebooks/ Ordner in der Cloud bereithält, braucht es auf dem Boox Go 7 nur drei Schritte:

1. OpenCloud App aus dem Play Store installieren
2. Mit der eigenen cloud.pandolin.online Instanz verbinden
3. Den /ebooks/ Ordner öffnen, Buch antippen → „Öffnen mit" → Reader-App auswählen

Das war's. Die Bücher landen im Download-Ordner, die Reader-App erkennt sie beim ersten Öffnen, danach liegen sie dauerhaft im Bücherregal, genau wie bei Kindle, nur ohne Überwachung, ohne Vendor Lock-in und ohne "Was wir meinen, was Sie lesen sollten ...". Befreiung vom Upsell & vom Algorithmus.

Kleiner Workflow-Hinweis: Die OpenCloud Android App hat (Stand März 2026) noch keinen konfigurierbaren lokalen Sync-Pfad. Als ehrliches Feedback ans OpenCloud-Team, fixt das bitte. Der Workaround – einmal pro Buch antippen – ist für die Zielgruppe aber absolut zumutbar.

Wo bekommt man DRM-freie Bücher?

Das ist die eigentlich politische Frage. Es ist besser geworden, aber noch nicht gut genug.

• beam-ebooks.de – Der beste deutschsprachige DRM-freie Store. Erste Anlaufstelle.

• Standard Ebooks: Hochwertig aufbereitete gemeinfreie Werke, kostenlos, EPUB-optimiert. Ich statte mich derzeit gerade da aus.
• Project Gutenberg: Der Urahn. Riesiges Archiv, vollständig frei.
• mises.org: Hayek, Mises, Rothbard – oft kostenlos und DRM-frei. Hayeks „Die Anmaßung von Wissen" (sollten wir alle jeden tag lesen) gibt es dort direkt.

Die unbequeme Wahrheit: Aktuelle Mainstream-Sachbücher wie Zuboff, Peterson, Solschenizyn, kommen fast ausnahmslos mit DRM.
Die bittere Ironie: Ausgerechnet „Das Zeitalter des Überwachungskapitalismus" bekommt man kaum ohne Überwachungs-DRM. Legaler Weg: Beam (EPUB statt Kindle-Format) oder Ausleihe via Libby/OverDrive.

Warum das zusammenpasst

OpenCloud als Ebook-Bibliothek schließt den Kreis: Vom selbst gehosteten Server über das offene Android-Gerät bis zur DRM-freien Datei liegt die gesamte Kette in eigenen Händen. Amazon hat keinen Einblick. Nur der Heinlein-Stack auf Caliban weiß, welche Bücher ich habe und schweigt darüber, weil er mir gehört. Danke dafür!

Lessons Learned: Meine Stolpersteine

• Der Variablen-Fluch: Die Variable heißt OC_URL, nicht OPENCLOUD_URL. Falsch gesetzt → WebUI zeigt „Fehlende oder falsche Konfiguration".
• Konfiguration ist in Stein gemeißelt: Nachträgliche Env-Änderungen wirken nicht, wenn die PVC bereits initialisiert ist. Lösung: PVCs löschen und neu starten.
• Admin-Passwort finden: Nur einmal beim ersten Start generiert. kubectl logs <pod-name> | grep -i password – und sofort danach eigenen User anlegen.

Fazit: Weniger ist mehr

Es ist ein gutes Gefühl, auf dieses neue Icon zu klicken. Es fühlt sich nicht nach „Hoffentlich geht heute nichts kaputt" an, der Service läuft, hat provozierte Abstürze und hartes Ausschalten mehrfach überstanden, das ist solide Infrastruktur. Digitaler Hausputz bedeutet 2026 auch, sich von alten Giganten zu trennen, um Platz für flinke, moderne Lösungen zu machen.

Wenn du genug vom Nextcloud-Wartungsmarathon hast, eine Alternative zu den alten Legacy-Hyperscalern suchst, dann wirf einen Blick auf OpenCloud. Und wenn du dabei gleich noch deinen Kindle in die Schublade legst oder vielleicht zu eBay weitergibst: umso besser.

Was nutzt ihr 2026 für eure Daten? Habt ihr den Absprung gewagt oder seid ihr noch Team PHP/Legacy-Hyperscaler? Schreibt es mir in die Kommentare!