Shiori zelf hosten in 2026: archieven, accounts en persistente opslag

Een mislukte Shiori-deployment crasht niet altijd. Er kan een loginpagina worden weergegeven terwijl het archiveren mislukt omdat Chromium-afhankelijkheden of filesystem-permissions verkeerd zijn ingesteld. Begin daarom met een end-to-end-controle: sla een bookmark met gearchiveerde content op, zoek deze op, bewerk de tags en controleer of het archief beschikbaar blijft nadat de bronpagina is gewijzigd.

Die controle sluit aan bij het in de catalogus beschreven doel van Shiori: een bookmarkmanager die pagina-inhoud archiveert. Ook worden ontbrekende afhankelijkheden, onjuiste aannames over de proxy en vluchtige data eerder zichtbaar dan met een uptime-probe.

De runtimegrens van Shiori bepalen

Procesgezondheid en productgezondheid zijn bij Shiori twee verschillende zaken. Poort 8080 kan reageren terwijl de transactie die de gebruiker uitvoert nog steeds mislukt. De externe vereiste voor Shiori is een beschrijfbaar datavolume en uitgaande toegang tot gearchiveerde pagina's. Test uitgaande DNS, TLS en het gedrag van providers zonder nog een andere inbound service te publiceren.

Gebruik deze readiness-oefening na ingrijpende configuratiewijzigingen: sla een bookmark met gearchiveerde content op, zoek deze op, bewerk de tags en controleer of het archief beschikbaar blijft nadat de bronpagina is gewijzigd. Houd dure externe controles buiten liveness-probes, zodat een storing bij een provider geen restart-loop veroorzaakt. Houd bij capaciteitsplanning rekening met browsergebaseerde paginacaptures, archiefgrootte, thumbnails en uitgaande requests; die geven een beter beeld van de werkelijke belasting van Shiori dan paginarequests.

Shiori herstellen op een lege host

Breng de state in kaart voordat het eerste echte record wordt aangemaakt: database, gearchiveerde pagina-inhoud, thumbnails en configuratie. Mount /shiori vóór de bootstrap, schrijf ongevaarlijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Controleer de mount door ongevaarlijke data te schrijven, Shiori te vervangen en de data opnieuw uit te lezen.

Snapshots zijn waardevol voor een snelle rollback, maar er is een onafhankelijke back-up nodig als de host of het volume verdwijnt. Herstel naar een lege omgeving met de vastgezette image en controleer of bookmarks, tags, archiefbestanden en accounts terugkomen en een dode bronlink nog steeds de opgeslagen content opent. Gebruik persistente volumes en snapshots om deze twee recoverymechanismen van elkaar te onderscheiden.

Beveiligingsbeslissingen die specifiek zijn voor Shiori

Het specifieke beveiligingsrisico van de applicatie is dat het initiële account ongewijzigd blijft op een publiek toegankelijke instance. Het operationele antwoord is het vervangen van het initiële account, het beperken van publiek delen en het behandelen van gearchiveerde private URL's als gevoelige content. Rond de bootstrap af via een afgeschermde route en verwijder tijdelijke toegang tot de setup direct daarna.

SHIORI_DIR bepaalt het gedrag, niet de vertrouwelijkheid; valideer het type en de waarde ervan en sla echte Shiori-credentials afzonderlijk op. Geef het Shiori-proces alleen de gedocumenteerde mounts en dependency-routes; vermijd toegang tot de root van de host en de Docker-socket. Log mislukte authenticatie en configuratiefouten, maar maskeer tokens, connection strings en gebruikerscontent.

Een production-acceptatietest voor Shiori

Een release candidate van Shiori verdient productiegebruik door een vast scenario succesvol af te ronden: sla een bookmark met gearchiveerde content op, zoek deze op, bewerk de tags en controleer of het archief beschikbaar blijft nadat de bronpagina is gewijzigd. Leg voor dit scenario de image-digest, de effectieve configuratie zonder secrets, de publieke origin en de tijdstippen vast. De testdata moet wegwerpbaar zijn, maar realistisch genoeg om hetzelfde pad als echte gebruikers te testen.

Voer de test uit nadat de runtime is vervangen en bouw de service vervolgens opnieuw op vanuit de database, gearchiveerde pagina-inhoud, thumbnails en configuratie. Recovery is geslaagd wanneer bookmarks, tags, archiefbestanden en accounts terugkomen en een dode bronlink nog steeds de opgeslagen content opent. Vergelijk de resource-metingen voor browsergebaseerde paginacaptures, archiefgrootte, thumbnails en uitgaande requests met de vorige release en onderzoek betekenisvolle afwijkingen voordat je de release promoot.

Voer ten slotte deze gecontroleerde fout uit: blokkeer tijdelijk het testpad dat wordt gebruikt door een beschrijfbaar datavolume en uitgaande toegang tot gearchiveerde pagina's. Controleer of Shiori de fout uitlegt, bestaande state niet beschadigt en na het herstellen van de juiste voorwaarde weer verdergaat. Bewaar een geredigeerd logfragment en de hersteltijd. Samen dekken deze controles gedrag, duurzaamheid en beheerbaarheid af, in plaats van alleen de uptime van het proces.

Shiori starten met observeerbare defaults

Houd de initiële aanroep van Shiori voldoende reproduceerbaar om deze in een pull request te kunnen beoordelen.

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

Vertrouw niet op latest zodra er echte data aanwezig is. Leg de werkende digest, de containergebruiker en het eigenaarschap van de mount vast. Volg het applicatielogboek tijdens een volledige test — sla een bookmark met gearchiveerde content op, zoek deze op, bewerk de tags en controleer of het archief beschikbaar blijft nadat de bronpagina is gewijzigd — en noteer eventuele migrations voordat je de route achter production traffic plaatst.

Domeinen, proxyheaders en poort 8080

Behandel de externe Shiori-URL als configuratie die redeployments overleeft. Routeer eerst de UI en API via een stabiele HTTPS-origin; routeer vervolgens de hostname naar poort 8080, waarbij de oorspronkelijke host en scheme intact blijven.

De checklist voor bereikbaarheid van deployments kan aantonen dat requests de container binnenkomen. Daarna moet de bekende fout — het archiveren mislukt omdat Chromium-afhankelijkheden of filesystem-permissions verkeerd zijn ingesteld — in Shiori, de state ervan of de workload worden onderzocht, en niet in de certificate automation.

Shiori upgraden zonder giswerk

De eerste nuttige operationele metric voor Shiori is of het een bookmark met gearchiveerde content kan opslaan, deze kan doorzoeken, de tags kan bewerken en kan verifiëren dat het archief beschikbaar blijft nadat de bronpagina is gewijzigd. Combineer dit met saturation-signalen voor browsergebaseerde paginacaptures, archiefgrootte, thumbnails en uitgaande requests. Een probe die alleen het proces controleert, mag geen dure dependencies aanroepen of de container herstarten omdat een upstream tijdelijk niet beschikbaar is.

Behandel upgrades als datamutaties, omdat database-migrations van Shiori en dependencies voor page capture het gedrag van archieven kunnen veranderen. Pin versies, oefen op herstelde state en houd de vorige image beschikbaar totdat een rollback geldig blijft. Als het archiveren mislukt omdat Chromium-afhankelijkheden of filesystem-permissions verkeerd zijn ingesteld, bewaar dan de logs van vóór de restart; daarin staat meestal de oorzaak.

Wat Dockup voor Shiori moet automatiseren

De platformlaag voor Shiori bestaat uit poort 8080, ingress, TLS, runtimeconfiguratie, opslag en bereikbaarheid van dependencies. Dockup kan deze onderdelen reproduceren voor de eigen infrastructuur of voor een server die de klant koppelt.

Daarna rondt de operator de productlaag af: routeer de UI en API via een stabiele HTTPS-origin; dwing deze toegangsregel af — vervang het initiële account, beperk publiek delen en behandel gearchiveerde private URL's als gevoelige content — en voer “sla een bookmark met gearchiveerde content op, zoek deze op, bewerk de tags en controleer of het archief beschikbaar blijft nadat de bronpagina is gewijzigd” uit. Door die test samen met de deployment vast te leggen, voorkom je dat geautomatiseerde provisioning wordt verward met applicatiereadiness.

Veelgestelde vragen

Wat heeft Shiori nodig voor een production-deployment?

Routeer de Shiori-container op poort 8080 via één HTTPS-origin. De externe deliveryvereiste is een beschrijfbaar datavolume en uitgaande toegang tot gearchiveerde pagina's. Markeer Shiori pas als ready wanneer je een bookmark met gearchiveerde content kunt opslaan, deze kunt doorzoeken, de tags kunt bewerken en kunt controleren of het archief beschikbaar blijft nadat de bronpagina is gewijzigd.

Welke Shiori-data hoort in een back-up?

Maak /shiori persistent en neem de database, gearchiveerde pagina-inhoud, thumbnails en configuratie op in hetzelfde recovery-manifest. Een schone Shiori-restore is alleen geslaagd wanneer bookmarks, tags, archiefbestanden en accounts terugkomen en een dode bronlink nog steeds de opgeslagen content opent.

Heeft Shiori HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Shiori-origin en houd poort 8080 op de interne route. Pas de Shiori-instelling correct toe: routeer de UI en API via een stabiele HTTPS-origin. Voor Shiori beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent clientgedrag dat afhankelijk is van de origin.

Hoe moet een Shiori-upgrade worden getest?

Herstel de huidige Shiori-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier vooral op, omdat database-migrations van Shiori en dependencies voor page capture het gedrag van archieven kunnen veranderen. Houd de vorige Shiori-image beschikbaar totdat de grens voor datamigratie en rollback duidelijk is.