Wallabag zelf hosten in 2026: imports, database en achtergrondtaken
Een praktische handleiding voor het zelf hosten van Wallabag met aandacht voor Docker, poorten, persistente data, TLS, beveiliging, backups en problemen die productiegebruik in de weg staan. Inclusief controles.
De kortste Wallabag-demo bewijst alleen dat een proces op poort 80 luistert. Voor productie is sterker bewijs nodig. Deze situatie moet ook slagen nadat de container is vervangen: sla een normaal artikel en een lastige pagina op, voer het ophalen op de achtergrond uit, synchroniseer een mobiele client en zoek in gearchiveerde content.
Wallabag wordt met een duidelijk doel uitgerold: als read-it-later-archief dat paginaruis verwijdert. De meest voorkomende valkuil bij deployments is dat assets of login-redirects HTTP gebruiken omdat de domeinvariabele verkeerd is ingesteld. Daarom verdienen de afhandeling van de publieke URL en duurzame state net zoveel aandacht als het opstarten van de image.
Maak van de lokale opdracht een inspecteerbare service
Met de volgende opdracht wordt de containergrens zichtbaar, zonder te doen alsof alle externe services worden geprovisioned.
docker run -d \
--name wallabag \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v wallabag-data:/var/www/wallabag/data \
-e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
wallabag/wallabag:latest
Inspecteer voordat je ingress opent de opgeloste environment, mounts en listener. Voeg de gecontroleerde verbindingsinstellingen toe voor Postgres of MariaDB, Redis en geplande import workers; gebruik private namen voor private services. Een succesvolle start is pas bereikt wanneer je een normaal artikel en een lastige pagina kunt opslaan, het ophalen op de achtergrond kunt uitvoeren, een mobiele client kunt synchroniseren en in gearchiveerde content kunt zoeken — niet wanneer docker ps Up toont.
Waar Wallabag van afhankelijk is
Trek drie grenzen rond Wallabag: ingress naar poort 80, duurzame state en ondersteunende vereisten. De container kan worden vervangen, maar voor de andere twee moeten expliciet verantwoordelijken worden aangewezen. Het netwerkcontract voor Wallabag bestaat uit Postgres of MariaDB, Redis en geplande import workers. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Wallabag een beperkte servicecredential.
Het diagram is compleet wanneer een schone client een normaal artikel en een lastige pagina kan opslaan, het ophalen op de achtergrond kan uitvoeren, een mobiele client kan synchroniseren en in gearchiveerde content kan zoeken. Leg timing- en resourcegegevens vast voor het ophalen van pagina's, parserwerk, image-downloads, queues en databasegroei. Als de transactie mislukt, laat de eerste grens die zich niet gedraagt zoals gedocumenteerd zien of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.
Beveilig Wallabag na de bootstrap
Neem beveiligingsaannames uit een lokale tutorial niet zomaar over. Het specifieke risico bij Wallabag is dat standaardcredentials behouden blijven of dat configuratie voor trusted proxies wordt overgeslagen. Verwijder daarom in productie de standaardcredentials, bescherm importtokens en configureer trusted proxies voordat je de reader openbaar maakt.
SYMFONY__ENV__DOMAIN_NAME is configuratie en geen secret; houd de waarde expliciet, maar bescherm de afzonderlijke credentials die Wallabag gebruikt. Beperk filesystem- en netwerktoegang, bescherm setup-endpoints en definieer limieten voor uploads, requests of uitvoering rond het ophalen van pagina's, parserwerk, image-downloads, queues en databasegroei.
Maak de publieke origin eenduidig
Stel één HTTPS-hostname beschikbaar voor Wallabag en houd de ruwe poort 80 private. Stel de domeinnaam in op de definitieve HTTPS-URL. Zo voorkom je dat browsers en API-clients twee concurrerende adressen leren kennen.
Voer vanaf een schone client de bekende geslaagde transactie uit en inspecteer het eerste request dat mislukt. Gebruik de handleiding voor een custom domain wanneer DNS of TLS niet correct is. Beschouw “assets of login-redirects gebruiken HTTP omdat de domeinvariabele verkeerd is” als een afzonderlijke applicatiediagnose zodra de route is bewezen.
Scheid vervangbare containers van blijvende data
De duurzame recovery-set bestaat uit de database, images, geïmporteerde content en configuratie. Mount /var/www/wallabag/data vóór de bootstrap, schrijf onschuldige voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een volume beschermt data tegen het vervangen van een container, maar niet tegen verlies van de host, onbedoelde verwijdering of corruptie op applicatieniveau.
Maak backups die de databron begrijpen: gebruik waar nodig logical dumps voor live databases en kopieer bestanden alleen vanuit een consistente toestand. Bewaar één versleutelde kopie buiten de Wallabag-host. Het acceptatiecriterium voor een restore is specifiek: artikelen, tags, annotaties, gebruikers en API-tokens zijn terug en de mobiele client synchroniseert. De handleiding voor restore-geteste backups legt uit waarom alleen een geslaagde job onvoldoende is.
Verzamel bewijs voordat Wallabag live gaat
Definieer voor Wallabag vóór de lancering een bekende geslaagde transactie: sla een normaal artikel en een lastige pagina op, voer het ophalen op de achtergrond uit, synchroniseer een mobiele client en zoek in gearchiveerde content. Zet de vereisten, verwachte response en opruimstappen ervan zonder secretwaarden in version control. Pin de image die je gebruikt om deze referentie vast te leggen.
Gebruik de transactie om een vervanging en een onafhankelijke restore te valideren. De herstelde service is pas acceptabel wanneer artikelen, tags, annotaties, gebruikers en API-tokens terug zijn en de mobiele client synchroniseert. Observeer tegelijkertijd het ophalen van pagina's, parserwerk, image-downloads, queues en databasegroei en maak van het traagste of meest beperkte onderdeel een service-level alert.
De gate heeft ook een negatieve testcase nodig: blokkeer tijdelijk de toegang van de testidentiteit tot Postgres of MariaDB, Redis en geplande import workers. Controleer of Wallabag een bruikbare foutmelding produceert en de data behoudt, herstel de geldige toestand en herhaal de bekende geslaagde transactie. Door beide resultaten te bewaren voorkom je dat een oppervlakkig health-endpoint het enige bewijs voor productie wordt.
Beheer Wallabag rond de echte bottleneck
Bouw dashboards rond het ophalen van pagina's, parserwerk, image-downloads, queues en databasegroei. Een CPU-grafiek zonder context van deze workload kan niet verklaren waarom Wallabag traag is. Voeg een synthetic of geplande check toe die met onschuldige testdata een normaal artikel en een lastige pagina probeert op te slaan, het ophalen op de achtergrond uitvoert, een mobiele client synchroniseert en in gearchiveerde content zoekt.
Houd vóór een upgrade rekening met dit applicatiespecifieke risico: Wallabag-migraties, parsergedrag en workerconfiguratie moeten worden getest met representatieve opgeslagen pagina's. Restore een recente backup naar een geïsoleerde deployment, voer daar de migraties uit en vergelijk het gedrag. Als assets of login-redirects HTTP gebruiken omdat de domeinvariabele verkeerd is ingesteld, inspecteer dan eerst de betrokken grens — publieke origin, storage of dependency — voordat je niet-gerelateerde instellingen wijzigt.
Gebruik Dockup voor de platformlaag
Voor Wallabag kan Dockup de route en het TLS-certificaat aanmaken, mounts behouden, secrets leveren en Postgres of MariaDB, Redis en geplande import workers op een private netwerk plaatsen, terwijl de deployment op Dockup of aangesloten servers wordt uitgevoerd.
De release gate blijft de concrete Wallabag-transactie: sla een normaal artikel en een lastige pagina op, voer het ophalen op de achtergrond uit, synchroniseer een mobiele client en zoek in gearchiveerde content. Controleer ook de restore-toestand: artikelen, tags, annotaties, gebruikers en API-tokens zijn terug en de mobiele client synchroniseert. Deze twee controles laten zien of de deployment werkt en of deze kan worden hersteld.
Veelgestelde vragen
Wat heeft Wallabag nodig voor een productie-deployment?
Routeer de Wallabag-container op poort 80 via één HTTPS-origin. De vereiste netwerkondersteuning bestaat uit Postgres of MariaDB, Redis en geplande import workers. Markeer Wallabag pas als gereed wanneer je een normaal artikel en een lastige pagina kunt opslaan, het ophalen op de achtergrond kunt uitvoeren, een mobiele client kunt synchroniseren en in gearchiveerde content kunt zoeken.
Welke Wallabag-data hoort in een backup?
Maak /var/www/wallabag/data persistent en neem de database, images, geïmporteerde content en configuratie op in hetzelfde recovery-manifest. Een schone Wallabag-restore slaagt pas wanneer artikelen, tags, annotaties, gebruikers en API-tokens terug zijn en de mobiele client synchroniseert.
Heeft Wallabag HTTPS nodig achter een reverse proxy?
Gebruik HTTPS voor de publieke Wallabag-origin en houd poort 80 op de interne route. Pas de Wallabag-instelling correct toe: stel de domeinnaam in op de definitieve HTTPS-URL. Voor Wallabag beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origin-gevoelig clientgedrag consistent blijft.
Hoe moet een Wallabag-upgrade worden getest?
Restore de huidige Wallabag-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat Wallabag-migraties, parsergedrag en workerconfiguratie moeten worden getest met representatieve opgeslagen pagina's. Bewaar de vorige Wallabag-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.