Wartung der Paperless Instanz auf dem UGREEN NAS – so betreibe ich Paperless professionell

von

Paperless-NGX läuft.
Die Dokumente kommen rein.
Alles ist durchsuchbar.

Und genau ab diesem Moment beginnt der Teil, über den kaum jemand schreibt: die Wartung.

Denn eine Paperless-Instanz, die einmal eingerichtet wurde und dann monatelang unbeaufsichtigt vor sich hin läuft, ist kein System – sie ist ein Risiko. Das habe ich ziemlich schnell gemerkt.

Also habe ich mir viele Gedanken gemacht, viel gelesen, Release Notes studiert, Dokus gewälzt und mir angeschaut, wie andere Paperless produktiv betreiben – nicht als Spielerei, sondern als zentrales Dokumentenarchiv.

Und dabei wurde mir klar:
Docker + latest + hoffen ist keine Strategie.

In diesem Artikel zeige ich dir, wie ich meine Paperless-Instanz auf der UGREEN NAS bewusst, kontrolliert und langfristig warte – und warum mir genau das heute ruhige Nächte beschert.

Warum Wartung bei Paperless mehr ist als „docker compose pull“

Ich kenne das selbst noch gut:
Neues Release, kurz docker compose pull, Container neu starten – läuft schon… meistens.

Aber genau dieses „meistens“ ist der Knackpunkt.

Paperless besteht nicht aus einem einzelnen Container. Es ist ein Stack aus mehreren Komponenten, die sauber zusammenspielen müssen. Ein ungeplantes Update an der falschen Stelle – und plötzlich hängt die Texterkennung, der Import bleibt stehen oder die Datenbank macht Probleme.

Für mich war klar:
Wenn Paperless mein digitales Archiv ist, dann muss es vorhersagbar, reproduzierbar und nachvollziehbar laufen.

Mein Paperless-NGX Setup auf der UGREEN NAS

Paperless läuft bei mir komplett containerisiert mit Docker Compose auf meiner UGREEN NAS.
Kein exotisches Setup, keine Experimente – sondern bewusst solide Technik.

Diese Komponenten gehören zu meinem Stack:

  • Paperless-NGX (Weboberfläche & Logik)
  • PostgreSQL als Datenbank
  • Redis als Message Broker
  • Gotenberg für Office- und E-Mail-Konvertierung
  • Apache Tika für Dokumentenanalyse und Textextraktion

Alle Container laufen in einem internen Docker-Netzwerk, sauber voneinander getrennt, ohne unnötige Portfreigaben. Genau so, wie ich es im produktiven Betrieb erwarte.

Das Grundprinzip meiner Wartungs- und Update-Strategie

Die wichtigste Entscheidung vorweg:

Es gibt bei mir keine automatischen Updates. Punkt.

Jede Änderung an meinem Paperless-Stack ist ein geplanter Change.
Nicht, weil ich Updates vermeiden will – sondern weil ich die Kontrolle behalten möchte.

Mein Ziel ist nicht „immer die neueste Version“, sondern:

  • Stabilität
  • Sicherheit
  • Kontrolle
  • Nachvollziehbarkeit

Oder anders gesagt:
Ich will jederzeit wissen was läuft, warum es läuft – und was sich ändert, wenn ich etwas anfasse.

Warum ich niemals „latest“ verwende

In meinem docker-compose.yml gibt es keinen einzigen floating Tag. Keine Ausnahmen.

So sehen die Image-Tags in meinem Setup aus:

  • Paperless-NGX: ghcr.io/paperless-ngx/paperless-ngx:2.20.3
  • PostgreSQL: postgres:16
  • Redis: redis:7.4.3
  • Gotenberg: gotenberg/gotenberg:8.25
  • Apache Tika: apache/tika:3.2.3.0

Der Vorteil liegt auf der Hand:
Mein System ist jederzeit reproduzierbar.

Wenn morgen etwas schiefläuft, weiß ich exakt:

  • welche Versionen im Einsatz waren
  • was zuletzt geändert wurde
  • und wo ich mit der Fehlersuche anfangen muss

Gerade auf einer NAS, die oft jahrelang durchläuft, ist das für mich kein Nice-to-have, sondern Pflicht.

Update-Strategie nach Komponententyp

Nicht jede Komponente wird gleich behandelt – und genau das macht den Unterschied.

Paperless-NGX selbst

Paperless beobachte ich aktiv.
Patch-Releases innerhalb einer Minor-Version spiele ich zeitnah ein – vor allem dann, wenn es um Security Fixes geht.

Ein typisches Beispiel:
Ein Update von 2.20.2 auf 2.20.3 habe ich gezielt eingespielt, weil ein Security Advisory veröffentlicht wurde.
Keine Nebenkomponenten wurden dafür angefasst.

Warum das problemlos funktioniert?
Paperless-Patch-Releases enthalten keine Breaking Changes, sondern Bugfixes und Sicherheitskorrekturen.

Redis

Redis betreibe ich bewusst innerhalb einer unterstützten Major-Version.
Paperless-NGX 2.x ist mit Redis 7.x kompatibel – und dabei bleibt es.

Updates mache ich hier nur bei:

  • relevanten Security Advisories
  • bekannten Bugfixes
  • geplanter Wartung

Und dann auch ausschließlich innerhalb der gleichen Major-Linie, z. B. von 7.4.3 auf 7.4.4.
Ein Major-Upgrade passiert nicht „mal eben“.

PostgreSQL – der kritischste Bestandteil

Die Datenbank ist das Herzstück des Systems.
Und genau deshalb gehe ich hier besonders konservativ vor.

Ich betreibe PostgreSQL bewusst auf einer festen Major-Version, aktuell PostgreSQL 16.

  • Minor-Updates innerhalb von 16.x ? ja, aber geplant
  • Major-Upgrade (z. B. 16 ? 17) ? eigenes Projekt

Mit Backup, Testlauf und Migrationsplan.
Alles andere wäre für mich fahrlässig.

Gotenberg

Gotenberg ist optional – aber für meinen Workflow extrem wichtig.
Die Major-Version 8 ist aktuell mit Paperless kompatibel.

Updates erfolgen nur bei:

  • bekannten Bugfixes
  • Performance-Verbesserungen
  • Security-Themen

Kein blindes Aktualisieren, kein Experimentieren im Produktivsystem.

Apache Tika

Apache Tika ist API-seitig sehr stabil.
Updates mache ich nur dann, wenn es einen konkreten Anlass gibt:

  • Parser-Fehler
  • Sicherheitslücken
  • Probleme mit bestimmten Dokumenttypen

Auch hier gilt: kein Automatismus.

So läuft ein Update bei mir wirklich ab

Über die Zeit habe ich mir einen festen Ablauf angewöhnt, den ich bei jeder Änderung konsequent einhalte:

  1. Neue Version identifizieren
  2. Kompatibilität mit Paperless prüfen
  3. Nutzen-/Risiko-Bewertung
  4. Entscheidung treffen
  5. Image-Tag im docker-compose.yml anpassen
  6. Backup erstellen
  7. Update durchführen
  8. Logs und Funktionen prüfen

Kein Schritt wird übersprungen.
Und ja – manchmal entscheide ich mich bewusst gegen ein Update. Auch das gehört dazu.

Backups & Sicherheit – Pflicht vor jeder Wartung

Vor jedem Update sichere ich:

  • die PostgreSQL-Datenbank
  • alle Paperless-Volumes
  • optional einen Snapshot der Host-Umgebung

Zugangsdaten liegen bei mir nicht im Klartext im Compose-File, sondern in:

  • Env-Files
  • oder Docker-Secrets

Das ist kein Overengineering – sondern einfach sauberes Arbeiten.

Warum sich diese Strategie im Alltag bewährt

Seit ich Paperless so betreibe, habe ich:

  • ein extrem stabiles System
  • keine bösen Überraschungen nach Updates
  • eine saubere Änderungs-Historie
  • eine schnelle Fehleranalyse, wenn doch mal etwas hakt

Und vor allem:
Ich vertraue meinem digitalen Archiv.

So betreibe ich Paperless bewusst nicht

Nur der Vollständigkeit halber:

  • kein latest
  • kein blindes docker compose pull
  • keine ungeplanten Major-Upgrades
  • kein Trial & Error im Produktivsystem

Das mag für Spielwiesen okay sein – für mein Archiv ist es das nicht.

Für wen diese Wartungsstrategie gedacht ist

Diese Herangehensweise richtet sich an:

  • fortgeschrittene Selfhoster
  • technikaffine Anwender
  • kleine Unternehmen
  • alle, die Paperless ernsthaft und langfristig nutzen wollen

Wenn du Paperless nur ausprobieren willst – fair enough.
Wenn du es als zentrales Dokumentenarchiv nutzt, wirst du dich hier sehr schnell wiederfinden.

Ergänzende Artikel zum Thema Paperless

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.