Paperless-ngx 3.x.x kontrolliert aktualisieren

Veröffentlicht am 28. Juli 2026 · zuletzt aktualisiert am 4. September 2026 / in Digitale Archive

Kurz gesagt

Aktueller Praxisstand vom 4. September 2026: Paperless-ngx 3.1.3 ist produktiv installiert. Die Migration von 3.1.2 auf 3.1.3 verlief einwandfrei. Das vorausgegangene Sicherheitsupdate 3.1.2 bleibt der zwingende Mindeststand; für eine neue Aktualisierung ist nun 3.1.3 das direkte Ziel.

Paperless-ngx wird in meinem produktiven Betrieb innerhalb der 3.x-Reihe gepflegt. Eine neue Version wird jedoch nicht allein wegen ihrer Versionsnummer installiert. Vor jedem Update prüfe ich Nutzen, Stabilität, bekannte Fehler und die Auswirkungen auf meinen vorhandenen Archiv-Workflow.

Stabilität vor Funktionsgewinn. Ein funktionierendes Produktivsystem wird nur verändert, wenn ein konkreter Nutzen, Sicherheit oder eine technische Notwendigkeit die Änderung rechtfertigt.

Paperless-ngx ist dabei Werkzeug und Arbeitsoberfläche, nicht das eigentliche Langzeitarchiv. Entscheidend bleiben portable Dokumente, OCR, Metadaten, nachvollziehbare Strukturen, Export, Backup und dokumentierte Wiederherstellung. Meine Archivstrategie und die dauerhafte Dokumenthaltung hängen deshalb nicht von einer einzelnen Paperless-Version ab.

Die grundlegende Migration von Paperless-ngx 2.20.15 auf Version 3 beschreibt der separate Praxisbericht zum Major-Upgrade.

Mein dokumentierter Praxisstand

Paperless-ngx ist seit dem 1. Januar 2026 mein operatives Dokumentenwerkzeug. Am 2. September 2026 habe ich die produktive Installation wegen des veröffentlichten Sicherheitsupdates unmittelbar auf Paperless-ngx 3.1.2 aktualisiert. Am 4. September folgte das Korrekturrelease 3.1.3; die dabei ausgeführten Migrationen liefen einwandfrei durch. Die Installation läuft auf Debian mit Docker, SQLite, Tika und Gotenberg.

Unmittelbar vor dem Versionswechsel lief ein zusätzlicher Borg-Sicherungslauf mit konsistentem SQLite-Snapshot erfolgreich durch. Erst nach dessen bestätigtem Abschluss wurden die Container-Images geladen und die Dienste neu erstellt. Paperless führte beim ersten Start die vorgesehenen Datenbankmigrationen aus und meldete den Suchindex als aktuell.

Das Backup wurde vor dem Update gezogen. Der erfolgreiche Sicherungslauf war die Voraussetzung für den anschließenden Image-Pull und Neustart der Container.

Nach dem Update auf 3.1.2 war der Paperless-Container gesund, die Weboberfläche erreichbar und die Django-Systemprüfung ohne Befund. Es waren keine Datenbankmigrationen mehr offen; Paperless meldete den Suchindex als aktuell. 2.668 vorhandene Dokumente waren weiterhin in der Datenbank erfasst, und eine Kontrollsuche lieferte erwartungsgemäß Treffer. Auch die anschließende Migration auf 3.1.3 verlief einwandfrei.

Meine Update-Klassifizierung

Paperless-ngx 3.1.3: Korrekturstand vom 4. September 2026

Paperless-ngx 3.1.3 wurde am 4. September 2026 veröffentlicht. Die offiziellen Release Notes zu Paperless-ngx 3.1.3 nennen vor allem Fehlerkorrekturen und zusätzliche technische Härtungen. Korrigiert wurden unter anderem Fehler beim Einreihen von Dateien zur Verarbeitung, bei Celery-Mailaufgaben, bei der Anwendung von KI-Vorschlägen nach dem Dokumentimport und bei der Dateinamenerzeugung aus Dokumentmetadaten. Hinzu kommen Verbesserungen an Oberfläche und Abhängigkeiten.

Für meine Installation ist 3.1.3 der aktuelle produktive Zielstand. Der Wechsel von 3.1.2 auf 3.1.3 einschließlich der vorgesehenen Migrationen verlief einwandfrei. Damit bestätigt sich der bewährte Weg: erst sichern, dann kontrolliert aktualisieren und anschließend den technischen sowie fachlichen Betrieb prüfen.

Für Docker sollte der freigegebene Stand fest in docker-compose.yml eingetragen werden:

image: ghcr.io/paperless-ngx/paperless-ngx:3.1.3

Paperless-ngx 3.1.2: vorausgegangenes Sicherheitsupdate

Paperless-ngx 3.1.2 wurde am 1. September 2026 veröffentlicht. Laut den offiziellen Release Notes zu Paperless-ngx 3.1.2 behebt die Version ein Sicherheitsproblem mit der Kennung GHSA-2jhj-xqrq-rmrq. Die Entwickler empfehlen das Release ausdrücklich allen Anwendern.

Damit ist meine Einordnung eindeutig: Klasse A – zwingend. Anders als bei einem reinen Funktions- oder Komfortupdate ist Abwarten hier nicht die richtige Entscheidung. Wer Paperless-ngx betreibt, soll auf jeden Fall auf 3.1.2 aktualisieren. Backup, kontrollierter Neustart und Funktionsprüfung bleiben trotzdem unverzichtbar.

Die Zwischenversionen 3.1.0 und 3.1.1 sind für eine heutige Updateentscheidung überholt. 3.1.2 war wegen der Sicherheitskorrektur zwingend; nach Erscheinen und erfolgreicher eigener Migration ist 3.1.3 nun das direkte Ziel. Mit docker compose pull wird das fest eingetragene Image aus der offiziellen GitHub Container Registry geladen. Vor dem Pull müssen ein erfolgreiches Backup und der Rückweg geprüft sein.

Stand 04.09.2026: 3.1.3 ist produktiv installiert; die Migration von 3.1.2 verlief einwandfrei. Die Sicherheitskorrektur aus 3.1.2 ist in diesem Stand enthalten.

Warum das Update auf 3.1.2 zwingend ist

3.1.2 ist kein bloßes Funktions- oder Komfortupdate. Es schließt ein bestätigtes Sicherheitsproblem und wird von den Entwicklern allen Anwendern empfohlen. Damit entfällt die sonst sinnvolle Beobachtungsphase.

Das Update erfolgt nicht wegen AI-Suggestions, Remote OCR oder anderer neuer Funktionen. Diese Funktionen werden dadurch nicht automatisch Bestandteil meiner Arbeitsweise. Ausschlaggebend ist allein die Sicherheitskorrektur.

Deshalb gilt aktuell:

Stabilität vor Versionsaktualität bedeutet hier: Das bestätigte Sicherheitsupdate 3.1.2 wird nicht aufgeschoben, sondern nach erfolgreichem Backup kontrolliert installiert und geprüft.

KI-Funktionen: technisch interessant, derzeit nicht erforderlich

Die optionalen KI- und LLM-Funktionen habe ich für meine Installation geprüft, setze sie derzeit aber nicht produktiv ein. Eine externe KI-API würde zusätzliche laufende Kosten und einen weiteren Datenfluss erzeugen; ein lokaler LLM-Betrieb würde zusätzliche beziehungsweise stärkere Hardware erfordern. Da OCR, Volltextsuche, Metadaten und die vorhandenen Workflows meinen Bedarf bereits abdecken, bleibt die Erweiterung für mich derzeit ein Nice-to-have.

Die ausführliche Architekturentscheidung steht im Praxisartikel KI in Paperless-ngx.

Consumer und Dateieinzug beim Update prüfen

Änderungen innerhalb der Version 3 müssen beim Consumer besonders beachtet werden. Die Version 3 führte dort eine andere Überwachung des Consume-Verzeichnisses und geänderte Einstellungen ein. Ignore-Patterns werden als reguläre Ausdrücke statt als fnmatch-Muster interpretiert; Verzeichnisse und Dateien werden getrennt behandelt. Bestehende Consumer- und Ignore-Konfigurationen müssen bei einem Versionswechsel deshalb anhand der aktuellen Dokumentation geprüft werden.

Für meine Installation sind insbesondere diese beiden Werte relevant:

PAPERLESS_CONSUMER_POLLING_INTERVAL=30
PAPERLESS_CONSUMER_STABILITY_DELAY=30

Beide Werte betragen in der laufenden Installation 30 Sekunden. Der Consumer arbeitet weiterhin rekursiv, und Unterordner werden weiterhin als Tags übernommen. Diese Werte sind der am 1. September 2026 live geprüfte Konfigurationsstand; sie sind keine allgemeine Empfehlung für andere Installationen.

Auch der rekursive Einzug und die Zuordnung von Unterordnern als Tags müssen mit einem Testdokument kontrolliert werden. Aus den notwendigen Konfigurationsprüfungen folgt keine pauschale Aussage, dass SMB/CIFS oder Polling in 3.1.2 grundsätzlich fehlerhaft seien.

Feste Versionsnummer statt latest

Ein unkontrollierter latest-Tag ist für einen reproduzierbaren Produktivbetrieb ungünstig. Er bezeichnet keine dauerhaft festgelegte Version und kann bei einem späteren docker compose pull ein anderes Image liefern, obwohl die Compose-Datei nicht bewusst auf diese Versionsnummer umgestellt wurde.

Ein normaler Neustart der Hardware lädt dagegen nicht von selbst ein neues Image. Zum Versionswechsel kommt es erst, wenn ein Image geladen und der Container damit neu erstellt wird, etwa durch docker compose pull und anschließend docker compose up -d oder durch eine Aktualisierungsautomatik.

Beim Update am 2. September 2026 verwendete die bestehende Compose-Datei ghcr.io/paperless-ngx/paperless-ngx:latest; dieser Tag lieferte zu diesem Zeitpunkt 3.1.2. Das Update ist damit dokumentiert und technisch geprüft, die Compose-Datei bildet die freigegebene Zielversion aber noch nicht dauerhaft ab.

Eine feste Versionsnummer erleichtert Reproduzierbarkeit, Dokumentation und gegebenenfalls den Rückweg. Die daraus folgende technische Nacharbeit ist deshalb, den beweglichen Tag kontrolliert durch 3.1.3 oder einen unveränderlichen Image-Digest zu ersetzen. Ein Pull allein ist keine Freigabeentscheidung.

Ablauf und Prüfung der ausgeführten Updates

Beim Update auf 3.1.2 bin ich in dieser Reihenfolge vorgegangen:

1. BorgBackup ausführen beziehungsweise den aktuellen Backupstand prüfen.
2. Einen konsistenten SQLite-Snapshot sicherstellen.
3. .env und docker-compose.yml sichern.
4. Offizielle Release Notes lesen.
5. Consumer- und Ignore-Konfiguration prüfen.
6. Image- und Versionsstand vor dem Wechsel dokumentieren.
7. Images laden und die Container neu erstellen beziehungsweise starten.
8. Den vollständigen ersten Start einschließlich Datenbankmigrationen abwarten.
9. Dokumentbestand, SQLite-Integrität und ausstehende Migrationen prüfen.
10. Suchindex, Weboberfläche, Containerzustand, Tika, Gotenberg und Logs kontrollieren.

Die technische Prüfung unmittelbar nach dem Update war erfolgreich. Ein frisches Borg-Archiv wurde vor dem Wechsel abgeschlossen, das Image vollständig geladen und der Compose-Stack neu erstellt. Der Container meldete healthy, es gab keine offenen Migrationen, Django meldete keine Systemfehler und der Suchindex war aktuell. Gespeicherte Ansichten, Workflows, Consumer-Abläufe und die weitere Sicherungsfähigkeit werden zusätzlich im normalen Betrieb beobachtet. Das alte Paperless-Image wurde nicht vorschnell entfernt. Auf einen pauschalen Befehl wie docker system prune -a verzichte ich in der produktiven Umgebung.

Tika und Gotenberg nach dem Update

Paperless nutzt in dieser Installation zwei getrennte Hilfsdienste für Office-Dokumente und Konvertierungen:

Gotenberg 8.36.0 enthält unter anderem einen Sicherheitsfix für WebSocket-Verbindungen sowie Verbesserungen an PDF-Optimierung und Konvertierung. Tika 4.0.0 ist dagegen ein Major-Upgrade mit geänderter Ausgabe- und Serverarchitektur. Für den Paperless-Betrieb zählt deshalb nicht die höchste verfügbare Tika-Versionsnummer, sondern die nachweislich kompatible Dienstkette.

Fazit

Paperless-ngx muss nicht deshalb aktualisiert werden, weil eine neue Versionsnummer verfügbar ist. Entscheidend ist, ob eine neue Version für den eigenen Betrieb einen konkreten Nutzen bringt oder relevante Fehler beseitigt.

Für meine produktive Installation bedeutet das: Das Sicherheitsupdate auf 3.1.2 wurde am 2. September 2026 nach einem frischen BorgBackup unverzüglich installiert. Am 4. September folgte 3.1.3; die Migration verlief einwandfrei. Der aktuelle produktive Zielstand ist damit 3.1.3.

Die Handlungsanweisung bleibt eindeutig: Nicht unter 3.1.2 bleiben und bei einer aktuellen Aktualisierung direkt 3.1.3 installieren. Nicht ungesichert und nicht blind, aber ohne unnötigen Aufschub.

Ein dokumentiertes und zuverlässig gesichertes Archiv ist wichtiger als die jeweils neueste Softwareversion.

Quellen und Stand

Weiterführend

• Paperless-ngx 3.0 sicher aktualisieren: ein Praxisbericht – Major-Upgrade, reale Tests und Rollback-Konzept
• Governance für Paperless-ngx – dauerhafte Regeln für OCR, Metadaten und Automatisierung
• KI in Paperless-ngx – Vorschläge, Datenschutz und menschliche Kontrolle
• Paperless-ngx zuverlässig sichern – Backup, Export und Wiederherstellbarkeit
• Paperless-ngx in der Praxis: Arbeitsabläufe, Regeln und Kontrolle – kontrollierte Abläufe im laufenden Dokumentenarchiv