Sådan selvhoster du Wallabag i 2026: Importer, database og baggrundsjob

Den korteste Wallabag-demo beviser, at en proces lytter på port 80. Produktion kræver stærkere dokumentation. Den skal kunne gennemføre dette scenarie, selv efter at containeren er blevet udskiftet: Gem en normal artikel og en vanskelig side, kør baggrundshentning, synkroniser en mobilklient, og søg i arkiveret indhold.

Wallabag deployes med et klart formål: et read-it-later-arkiv, der fjerner overflødigt indhold fra sider. Den mest almindelige deployment-fælde er, at assets eller login-redirects bruger HTTP, fordi domænevariablen er forkert. Derfor skal håndteringen af den offentlige URL og persistent state have samme opmærksomhed som opstarten af imaget.

Gør den lokale kommando til en service, der kan inspiceres

Følgende kommando gør containergrænsen synlig uden at lade som om, at alle eksterne services provisioneres.

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

Før du åbner for ingress, skal du inspicere det resolvede miljø, mounts og listeneren. Tilføj de gennemgåede connection settings for Postgres eller MariaDB, Redis og scheduled import workers, og brug private navne til private services. En vellykket opstart er først færdig, når du kan gemme en normal artikel og en vanskelig side, køre baggrundshentning, synkronisere en mobilklient og søge i arkiveret indhold – ikke når docker ps viser Up.

Hvad Wallabag afhænger af

Tegn tre grænser omkring Wallabag: ingress til port 80, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre kræver tydelige ejere. Wallabags netværkskontrakt består af Postgres eller MariaDB, Redis og scheduled import workers. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Wallabag en afgrænset service credential.

Diagrammet er komplet, når en ren klient kan gemme en normal artikel og en vanskelig side, køre baggrundshentning, synkronisere en mobilklient og søge i arkiveret indhold. Indsaml data om timing og ressourceforbrug for sidehentning, parserarbejde, billeddownloads, køer og databasevækst. Hvis transaktionen fejler, viser den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.

Hærd Wallabag efter bootstrap

Du må ikke overføre sikkerhedsantagelser fra en lokal tutorial. Wallabags specifikke risici er at beholde standardcredentials eller springe konfigurationen af trusted proxies over. Produktion bør derfor fjerne standardcredentials, beskytte import tokens og konfigurere trusted proxies, før readeren eksponeres.

SYMFONY__ENV__DOMAIN_NAME er konfiguration og ikke en secret; hold værdien eksplicit, og beskyt de separate credentials, som Wallabag bruger. Afgræns filsystem- og netværksadgang, beskyt setup-endpoints, og definér grænser for upload, requests eller execution omkring sidehentning, parserarbejde, billeddownloads, køer og databasevækst.

Gør den offentlige origin entydig

Eksponér ét HTTPS-hostnavn for Wallabag, og hold rå port 80 privat. Angiv domænenavnet som den endelige HTTPS-URL. Det forhindrer browsere og API-klienter i at opdage to konkurrerende adresser.

Kør den kendte, velfungerende transaktion fra en ren klient, og inspicér den første request, der fejler. Brug guiden til custom domains, når DNS eller TLS er forkert. Betragt “assets eller login-redirects bruger HTTP, fordi domænevariablen er forkert” som en separat applikationsdiagnose, når routen er bevist.

Adskil udskiftelige containere fra varige data

Det varige recovery-sæt består af database, images, importeret indhold og konfiguration. Mount /var/www/wallabag/data før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Et volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller korruption på applikationsniveau.

Tag backups, der forstår datakilden: Brug logical dumps til live-databaser, når det er nødvendigt, og kopiér kun filer fra en konsistent tilstand. Opbevar én krypteret kopi væk fra Wallabag-hosten. Acceptkriteriet for en restore er specifikt – artikler, tags, annotations, brugere og API-tokens skal gendannes, og mobilklienten skal synkronisere. Guiden til restore-testede backups forklarer, hvorfor et vellykket job alene ikke er tilstrækkeligt.

Dokumentation, der skal indsamles, før Wallabag går live

For Wallabag skal du definere en kendt, velfungerende transaktion før lanceringen: Gem en normal artikel og en vanskelig side, kør baggrundshentning, synkroniser en mobilklient, og søg i arkiveret indhold. Læg dens forudsætninger, forventede svar og oprydningstrin i version control uden secret values. Pin det image, der bruges til at etablere denne reference.

Brug transaktionen til at validere en udskiftning og en uafhængig restore. Den gendannede service er kun godkendt, når artikler, tags, annotations, brugere og API-tokens gendannes, og mobilklienten synkroniserer. Overvåg samtidig sidehentning, parserarbejde, billeddownloads, køer og databasevækst, og gør den langsomste eller mest begrænsede del til en service-level alert.

Gaten skal også have et negativt scenarie: Nægt midlertidigt testidentiteten adgang til Postgres eller MariaDB, Redis og scheduled import workers. Bekræft, at Wallabag genererer en handlingsanvisende fejl, samtidig med at data bevares. Gendan den gyldige tilstand, og gentag den kendte, velfungerende transaktion. Når begge resultater gemmes, forhindrer det, at et overfladisk health endpoint bliver den eneste dokumentation for produktion.

Driftssæt Wallabag omkring den reelle flaskehals

Byg dashboards omkring sidehentning, parserarbejde, billeddownloads, køer og databasevækst. En CPU-graf uden kontekst om denne workload kan ikke forklare, hvorfor Wallabag er langsom. Tilføj et syntetisk eller scheduled check, der forsøger at gemme en normal artikel og en vanskelig side, køre baggrundshentning, synkronisere en mobilklient og søge i arkiveret indhold med ufarlige testdata.

Før en opgradering skal du tage højde for denne applikationsspecifikke risiko: Wallabag-migrationer, parseradfærd og worker-konfiguration bør testes med repræsentative gemte sider. Gendan en nylig backup i en isoleret deployment, kør migrationerne dér, og sammenlign adfærden. Hvis assets eller login-redirects bruger HTTP, fordi domænevariablen er forkert, skal du inspicere den relevante grænse – public origin, storage eller dependency – før du ændrer andre indstillinger.

Brug Dockup til platformlaget

For Wallabag kan Dockup oprette routen og TLS-certifikatet, bevare mounts, levere secrets og placere Postgres eller MariaDB, Redis og scheduled import workers på et privat netværk, mens der deployes til enten Dockup eller tilknyttede servere.

Release-gaten er stadig den konkrete Wallabag-transaktion: Gem en normal artikel og en vanskelig side, kør baggrundshentning, synkroniser en mobilklient, og søg i arkiveret indhold. Bekræft også restore-tilstanden – artikler, tags, annotations, brugere og API-tokens skal gendannes, og mobilklienten skal synkronisere. De to kontroller viser, om deploymenten fungerer, og om den kan gendannes.

Ofte stillede spørgsmål

Hvad kræver Wallabag i en produktionsdeployment?

Route Wallabag-containeren på port 80 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres eller MariaDB, Redis og scheduled import workers. Kald ikke Wallabag klar, før du kan gemme en normal artikel og en vanskelig side, køre baggrundshentning, synkronisere en mobilklient og søge i arkiveret indhold.

Hvilke Wallabag-data hører hjemme i en backup?

Gør /var/www/wallabag/data persistent, og medtag database, images, importeret indhold og konfiguration i det samme recovery-manifest. En ren Wallabag-restore er kun godkendt, når artikler, tags, annotations, brugere og API-tokens gendannes, og mobilklienten synkroniserer.

Kræver Wallabag HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Wallabag-origin, og hold port 80 på den interne route. Anvend Wallabag-indstillingen korrekt: Angiv domænenavnet som den endelige HTTPS-URL. For Wallabag beskytter HTTPS credentials eller brugerindhold under transport og holder origin-følsom klientadfærd konsistent.

Hvordan bør en Wallabag-opgradering testes?

Gendan den aktuelle Wallabag-tilstand i en isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi Wallabag-migrationer, parseradfærd og worker-konfiguration bør testes med repræsentative gemte sider. Behold det tidligere Wallabag-image, indtil grænserne for datamigration og rollback er forstået.