Journal-IndexDockup / Feldnotiz
Note / self-host-shiori

Shiori 2026 selbst hosten: Archive, Konten und persistenter Speicher

Eine praxisnahe Anleitung zum Self-Hosting von Shiori mit Docker, Ports, persistenten Daten, TLS, Sicherheit, Backups und den Fehlern, die den Einsatz in der Produktion verhindern. Schritt für Schritt.

Eine fehlgeschlagene Shiori-Bereitstellung stürzt nicht immer ab. Möglicherweise wird eine Login-Seite ausgeliefert, während das Archivieren fehlschlägt, weil Chromium-Abhängigkeiten fehlen oder die Berechtigungen im Dateisystem nicht stimmen. Beginnen Sie stattdessen mit einer End-to-End-Prüfung: Speichern Sie ein Lesezeichen mit archiviertem Inhalt, suchen Sie danach, bearbeiten Sie die Tags und prüfen Sie, ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat.

Diese Prüfung entspricht dem dokumentierten Zweck von Shiori: ein Lesezeichenmanager, der Seiteninhalte archiviert. Außerdem deckt sie fehlende Abhängigkeiten, falsche Annahmen über den Proxy und flüchtige Daten früher auf als ein reiner Uptime-Test.

Die Laufzeitgrenze von Shiori festlegen

Prozessgesundheit und Produktgesundheit sind bei Shiori zwei verschiedene Dinge. Port 8080 kann antworten, während die Transaktion aus Sicht des Benutzers weiterhin fehlschlägt. Die externen Anforderungen von Shiori sind ein beschreibbares Daten-Volume und ausgehender Zugriff auf zu archivierende Seiten. Testen Sie ausgehendes DNS, TLS und das Verhalten des Providers, ohne einen weiteren eingehenden Dienst zu veröffentlichen.

Führen Sie diese Readiness-Prüfung nach wichtigen Konfigurationsänderungen aus: Speichern Sie ein Lesezeichen mit archiviertem Inhalt, suchen Sie danach, bearbeiten Sie die Tags und prüfen Sie, ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat. Halten Sie aufwendige externe Prüfungen aus Liveness-Probes heraus, damit ein Ausfall des Providers keine Restart-Schleife auslöst. Bei der Kapazitätsplanung sollten Sie browserbasierte Seitenerfassung, Archivgröße, Thumbnails und ausgehende Abrufe beobachten. Diese Faktoren spiegeln die tatsächliche Belastung von Shiori besser wider als Seitenanfragen.

Shiori auf einem leeren Host wiederherstellen

Erfassen Sie den Zustand, bevor der erste echte Datensatz erstellt wird: Datenbank, archivierte Seiteninhalte, Thumbnails und Konfiguration. Mounten Sie /shiori vor dem Bootstrap, schreiben Sie harmlose Beispieldaten und ersetzen Sie den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Bestätigen Sie das Mount, indem Sie harmlose Daten schreiben, Shiori ersetzen und die Daten anschließend wieder auslesen.

Snapshots sind für ein schnelles Rollback wertvoll. Wenn der Host oder das Volume jedoch verloren geht, benötigen Sie zusätzlich ein unabhängiges Backup. Stellen Sie die Daten in einer leeren Umgebung mit dem festgelegten Image wieder her und prüfen Sie, ob Lesezeichen, Tags, Archivdateien und Konten zurückkehren und ein nicht mehr erreichbarer Quelllink weiterhin seinen gespeicherten Inhalt öffnet. Verwenden Sie persistente Volumes und Snapshots, um diese beiden Wiederherstellungsmechanismen klar voneinander zu trennen.

Shiori-spezifische Sicherheitsentscheidungen

Das anwendungsspezifische Sicherheitsrisiko besteht darin, das initiale Konto auf einer öffentlich erreichbaren Instanz unverändert zu lassen. Die operative Konsequenz: Ersetzen Sie das initiale Konto, beschränken Sie die öffentliche Freigabe und behandeln Sie archivierte private URLs als vertrauliche Inhalte. Schließen Sie den Bootstrap über eine eingeschränkte Route ab und entfernen Sie den temporären Setup-Zugriff anschließend sofort.

SHIORI_DIR steuert das Verhalten, nicht die Vertraulichkeit. Prüfen Sie Typ und Wert und speichern Sie echte Shiori-Zugangsdaten getrennt. Geben Sie dem Shiori-Prozess nur die dokumentierten Mounts und Dependency-Routen; vermeiden Sie Zugriff auf das Root-Dateisystem des Hosts und den Docker-Socket. Protokollieren Sie fehlgeschlagene Authentifizierungen und Konfigurationsfehler, redigieren Sie jedoch Tokens, Connection Strings und Benutzerinhalte.

Ein Produktionsabnahmetest für Shiori

Ein Release Candidate von Shiori verdient sich produktiven Traffic, indem er ein festgelegtes Szenario erfolgreich durchläuft: Speichern Sie ein Lesezeichen mit archiviertem Inhalt, suchen Sie danach, bearbeiten Sie die Tags und prüfen Sie, ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat. Erfassen Sie für dieses Szenario den Image-Digest, die effektive Konfiguration ohne Secrets, die öffentliche Origin und die Zeitstempel. Die Testdaten sollten löschbar, aber realistisch genug sein, um denselben Pfad wie bei echten Benutzern zu testen.

Führen Sie den Test nach dem Ersetzen der Laufzeitumgebung aus und bauen Sie den Dienst anschließend aus Datenbank, archivierten Seiteninhalten, Thumbnails und Konfiguration neu auf. Die Wiederherstellung ist erfolgreich, wenn Lesezeichen, Tags, Archivdateien und Konten zurückkehren und ein nicht mehr erreichbarer Quelllink weiterhin seinen gespeicherten Inhalt öffnet. Vergleichen Sie die Ressourcenmesswerte für browserbasierte Seitenerfassung, Archivgröße, Thumbnails und ausgehende Abrufe mit dem vorherigen Release und untersuchen Sie signifikante Abweichungen, bevor Sie das Release freigeben.

Führen Sie abschließend diesen kontrollierten Fehlerfall aus: Verweigern Sie vorübergehend den Testpfad, der für ein beschreibbares Daten-Volume und den ausgehenden Zugriff auf zu archivierende Seiten verwendet wird. Prüfen Sie, ob Shiori den Fehler verständlich erklärt, den bestehenden Zustand nicht beschädigt und nach Wiederherstellung der korrekten Bedingungen weiterarbeitet. Speichern Sie einen redigierten Log-Auszug und die Wiederherstellungszeit. Zusammen decken diese Prüfungen Verhalten, Persistenz und Betriebsfähigkeit ab und nicht nur die Verfügbarkeit des Prozesses.

Shiori mit beobachtbaren Standardwerten starten

Halten Sie den initialen Shiori-Aufruf so reproduzierbar, dass er in einem Pull Request geprüft werden kann.

docker run -d \
  --name shiori \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v shiori-data:/shiori \
  -e SHIORI_DIR=/shiori \
  ghcr.io/go-shiori/shiori:latest

Verlassen Sie sich nicht auf latest, sobald echte Daten vorhanden sind. Erfassen Sie den funktionierenden Digest, den Container-Benutzer und den Eigentümer des Mounts. Verfolgen Sie das Anwendungslog über einen vollständigen Test hinweg — speichern Sie ein Lesezeichen mit archiviertem Inhalt, suchen Sie danach, bearbeiten Sie die Tags und prüfen Sie, ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat — und halten Sie alle Migrationen fest, bevor Sie die Route für produktiven Traffic freigeben.

Domains, Proxy-Header und Port 8080

Behandeln Sie die externe Shiori-URL als Konfiguration, die Deployments überdauert. Leiten Sie zunächst UI und API über eine stabile HTTPS-Origin weiter. Leiten Sie den Hostnamen anschließend an Port 8080 weiter und bewahren Sie dabei den ursprünglichen Host und das ursprüngliche Schema.

Mit der Checkliste zur Erreichbarkeit von Deployments können Sie nachweisen, dass Anfragen den Container erreichen. Ab diesem Punkt sollte der bekannte Fehler — das Archivieren schlägt fehl, weil Chromium-Abhängigkeiten fehlen oder die Berechtigungen im Dateisystem nicht stimmen — in Shiori, seinem Zustand oder seiner Workload untersucht werden und nicht in der Zertifikatsautomatisierung.

Shiori ohne Rätselraten aktualisieren

Die wichtigste operative Metrik für Shiori ist zunächst, ob ein Lesezeichen mit archiviertem Inhalt gespeichert, gesucht und mit bearbeiteten Tags versehen werden kann und ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat. Kombinieren Sie diese Metrik mit Sättigungssignalen für browserbasierte Seitenerfassung, Archivgröße, Thumbnails und ausgehende Abrufe. Eine reine Prozessprüfung sollte keine aufwendigen Abhängigkeiten aufrufen und den Container nicht neu starten, nur weil ein Upstream kurzzeitig nicht verfügbar ist.

Behandeln Sie Upgrades als Datenänderungen, da Datenbankmigrationen von Shiori und Abhängigkeiten für die Seitenerfassung das Archivverhalten verändern können. Pinnen Sie Versionen, proben Sie den Ablauf mit wiederhergestellten Daten und halten Sie das vorherige Image verfügbar, bis ein Rollback weiterhin möglich ist. Wenn das Archivieren fehlschlägt, weil Chromium-Abhängigkeiten fehlen oder die Berechtigungen im Dateisystem nicht stimmen, sichern Sie die Logs aus der Zeit vor dem Neustart. Sie enthalten in der Regel die ursächliche Fehlermeldung.

Was Dockup für Shiori automatisieren sollte

Die Plattformebene für Shiori umfasst Port 8080, Ingress, TLS, Laufzeitkonfiguration, Storage und die Erreichbarkeit von Abhängigkeiten. Dockup kann diese Komponenten für die eigene Infrastruktur oder für einen Server reproduzieren, den der Kunde verbindet.

Anschließend schließt der Betreiber die Produktebene ab: Leiten Sie UI und API über eine stabile HTTPS-Origin weiter; setzen Sie diese Zugriffsregel durch — ersetzen Sie das initiale Konto, beschränken Sie die öffentliche Freigabe und behandeln Sie archivierte private URLs als vertrauliche Inhalte — und führen Sie „Lesezeichen mit archiviertem Inhalt speichern, danach suchen, Tags bearbeiten und prüfen, ob das Archiv nach einer Änderung der Quellseite weiterhin verfügbar ist“ aus. Wenn dieser Test zusammen mit dem Deployment dokumentiert wird, lassen sich automatisierte Bereitstellung und Anwendungsbereitschaft klar voneinander unterscheiden.

Häufig gestellte Fragen

Was benötigt Shiori für ein produktives Deployment?

Leiten Sie den Shiori-Container auf Port 8080 über eine HTTPS-Origin weiter. Die externe Voraussetzung für die Auslieferung sind ein beschreibbares Daten-Volume und ausgehender Zugriff auf zu archivierende Seiten. Erklären Sie Shiori erst dann für bereit, wenn Sie ein Lesezeichen mit archiviertem Inhalt speichern, danach suchen, die Tags bearbeiten und prüfen können, ob das Archiv weiterhin verfügbar ist, nachdem sich die Quellseite geändert hat.

Welche Shiori-Daten gehören in ein Backup?

Machen Sie /shiori persistent und nehmen Sie Datenbank, archivierte Seiteninhalte, Thumbnails und Konfiguration in dasselbe Wiederherstellungsmanifest auf. Eine saubere Wiederherstellung von Shiori ist erst dann erfolgreich, wenn Lesezeichen, Tags, Archivdateien und Konten zurückkehren und ein nicht mehr erreichbarer Quelllink weiterhin seinen gespeicherten Inhalt öffnet.

Benötigt Shiori HTTPS hinter einem Reverse Proxy?

Verwenden Sie HTTPS für die öffentliche Shiori-Origin und belassen Sie Port 8080 auf der internen Route. Setzen Sie die Shiori-Konfiguration korrekt um: Leiten Sie UI und API über eine stabile HTTPS-Origin weiter. Bei Shiori schützt HTTPS Zugangsdaten und Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.

Wie sollte ein Shiori-Upgrade getestet werden?

Stellen Sie den aktuellen Shiori-Zustand in einem isolierten Deployment wieder her, wenden Sie die Kandidatenversion an und wiederholen Sie den Abnahmetest. Achten Sie besonders darauf, dass Datenbankmigrationen von Shiori und Abhängigkeiten für die Seitenerfassung das Archivverhalten verändern können. Halten Sie das vorherige Shiori-Image verfügbar, bis die Grenzen von Datenmigration und Rollback geklärt sind.