Slik selvhoster du Wallabag i 2026: importering, database og bakgrunnsjobber

Den korteste Wallabag-demoen beviser at en prosess lytter på port 80. Produksjon krever sterkere dokumentasjon. Tjenesten må bestå dette scenarioet selv etter at containeren er erstattet: lagre en vanlig artikkel og en vanskelig side, kjør bakgrunnshenting, synkroniser en mobilklient og søk i arkivert innhold.

Wallabag distribueres for et tydelig formål: et «les senere»-arkiv som fjerner overflødig innhold fra sider. Den vanligste fallgruven ved distribusjon er at ressurser eller innloggingsredirects bruker HTTP fordi domenevariabelen er feil. Derfor må håndtering av offentlige URL-er og persistent state få like mye oppmerksomhet som oppstart av imaget.

Gjør den lokale kommandoen om til en tjeneste du kan inspisere

Følgende kommando gjør containergrensen synlig uten å late som om alle eksterne tjenester 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 åpner ingress, bør du inspisere det effektive miljøet, mounts og lytteren. Legg til de gjennomgåtte tilkoblingsinnstillingene for Postgres eller MariaDB, Redis og planlagte import workers, og bruk private navn for private tjenester. En vellykket oppstart er først fullført når du kan lagre en vanlig artikkel og en vanskelig side, kjøre bakgrunnshenting, synkronisere en mobilklient og søke i arkivert innhold – ikke når docker ps skriver ut Up.

Hva Wallabag er avhengig av

Trekk tre grenser rundt Wallabag: ingress til port 80, persistent state og støttende krav. Containeren kan erstattes, men de to andre trenger tydelige eiere. Nettverkskontrakten for Wallabag består av Postgres eller MariaDB, Redis og planlagte import workers. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Wallabag en avgrenset tjenestekredential.

Diagrammet er komplett når en ren klient kan lagre en vanlig artikkel og en vanskelig side, kjøre bakgrunnshenting, synkronisere en mobilklient og søke i arkivert innhold. Samle inn tids- og ressursdata for sidelasting, parserarbeid, bildenedlastinger, køer og databasevekst. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert om du bør undersøke ruting, lokal kapasitet eller en støttetjeneste.

Sikre Wallabag etter bootstrap

Ikke viderefør sikkerhetsantakelser fra en lokal veiledning. Wallabags spesifikke utfordring er å unngå at standardpålogging beholdes eller at trusted proxy-konfigurasjon hoppes over. I produksjon bør du derfor fjerne standardpålogging, beskytte import tokens og konfigurere trusted proxies før leseren eksponeres.

SYMFONY__ENV__DOMAIN_NAME er konfigurasjon, ikke en secret. Hold verdien eksplisitt, samtidig som du beskytter de separate credentialene Wallabag bruker. Begrens tilgang til filsystem og nettverk, beskytt setup-endepunkter og definer grenser for opplasting, forespørsler eller kjøring rundt sidelasting, parserarbeid, bildenedlastinger, køer og databasevekst.

Gjør den offentlige origin entydig

Eksponer ett HTTPS-vertsnavn for Wallabag, og hold rå port 80 privat. Sett domenenavnet til den endelige HTTPS-URL-en. Dette hindrer nettlesere og API-klienter i å lære to konkurrerende adresser.

Kjør den kjente, fungerende transaksjonen fra en ren klient og inspiser den første forespørselen som feiler. Bruk veiledningen for egendefinert domene når DNS eller TLS er feil. Behandle «ressurser eller innloggingsredirects bruker HTTP fordi domenevariabelen er feil» som en separat applikasjonsdiagnose når routen er bekreftet.

Skill mellom containere som kan erstattes, og varige data

Det varige gjenopprettingssettet består av database, images, importert innhold og konfigurasjon. Mount /var/www/wallabag/data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at stien faktisk er persistent. Et volume beskytter data mot at containeren erstattes, men ikke mot tap av verten, utilsiktet sletting eller korrupsjon på applikasjonsnivå.

Ta sikkerhetskopier som forstår datakilden: bruk logical dumps for live-databaser når det er nødvendig, og kopier filer bare fra en konsistent tilstand. Oppbevar én kryptert kopi utenfor Wallabag-verten. Akseptansekriteriet for en restore er konkret – artikler, tags, annotasjoner, brukere og API tokens skal komme tilbake, og mobilklienten skal synkronisere. Veiledningen om sikkerhetskopier som er testet med restore forklarer hvorfor det ikke er nok at jobben rapporterer suksess.

Dokumentasjon du bør samle inn før Wallabag går live

For Wallabag bør du definere en kjent, fungerende transaksjon før lansering: lagre en vanlig artikkel og en vanskelig side, kjør bakgrunnshenting, synkroniser en mobilklient og søk i arkivert innhold. Legg forutsetninger, forventet respons og oppryddingstrinn i versjonskontroll uten secret-verdier. Pin imaget du bruker til å etablere denne referansen.

Bruk transaksjonen til å validere en erstatning og en uavhengig restore. Den gjenopprettede tjenesten er bare godkjent når artikler, tags, annotasjoner, brukere og API tokens er tilbake, og mobilklienten synkroniserer. Følg samtidig med på sidelasting, parserarbeid, bildenedlastinger, køer og databasevekst, og gjør den tregeste eller mest begrensede delen om til et service-level-varsel.

Kontrollpunktet trenger også et negativt tilfelle: nekt testidentiteten midlertidig tilgang til Postgres eller MariaDB, Redis og planlagte import workers. Bekreft at Wallabag gir en handlingsrettet feilmelding uten å miste data, gjenopprett den gyldige tilstanden og gjenta den kjente, fungerende transaksjonen. Når du tar vare på begge resultatene, hindrer du at et overfladisk health-endepunkt blir det eneste produksjonsbeviset.

Drift Wallabag rundt den faktiske flaskehalsen

Bygg dashboards rundt sidelasting, parserarbeid, bildenedlastinger, køer og databasevekst. En CPU-graf uten kontekst fra denne arbeidsbelastningen kan ikke forklare hvorfor Wallabag er treg. Legg til en synthetic eller planlagt kontroll som prøver å lagre en vanlig artikkel og en vanskelig side, kjøre bakgrunnshenting, synkronisere en mobilklient og søke i arkivert innhold ved hjelp av ufarlige testdata.

Før du oppgraderer, må du ta høyde for denne applikasjonsspesifikke risikoen: Wallabag-migreringer, parseroppførsel og worker-konfigurasjon bør testes mot representative lagrede sider. Gjenopprett en nylig sikkerhetskopi i en isolert distribusjon, kjør migreringer der og sammenlign oppførselen. Hvis ressurser eller innloggingsredirects bruker HTTP fordi domenevariabelen er feil, bør du inspisere den aktuelle grensen – offentlig origin, lagring eller avhengighet – før du endrer uvedkommende innstillinger.

Bruk Dockup til plattformlaget

For Wallabag kan Dockup opprette route og TLS-sertifikat, bevare mounts, levere secrets og plassere Postgres eller MariaDB, Redis og planlagte import workers på private nettverk, samtidig som løsningen distribueres til enten Dockup eller tilkoblede servere.

Release-kontrollen er fortsatt den konkrete Wallabag-transaksjonen: lagre en vanlig artikkel og en vanskelig side, kjør bakgrunnshenting, synkroniser en mobilklient og søk i arkivert innhold. Bekreft også restore-tilstanden – artikler, tags, annotasjoner, brukere og API tokens skal komme tilbake, og mobilklienten skal synkronisere. Disse to kontrollene viser om distribusjonen fungerer, og om den kan gjenopprettes.

Ofte stilte spørsmål

Hva trenger Wallabag for en produksjonsdistribusjon?

Rout Wallabag-containeren på port 80 gjennom én HTTPS-origin. Nettverkskravet for støttetjenestene er Postgres eller MariaDB, Redis og planlagte import workers. Ikke erklær Wallabag klar før du kan lagre en vanlig artikkel og en vanskelig side, kjøre bakgrunnshenting, synkronisere en mobilklient og søke i arkivert innhold.

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

Gjør /var/www/wallabag/data persistent, og inkluder database, images, importert innhold og konfigurasjon i det samme gjenopprettingsmanifestet. En ren Wallabag-restore er bare godkjent når artikler, tags, annotasjoner, brukere og API tokens kommer tilbake, og mobilklienten synkroniserer.

Krever Wallabag HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Wallabag-origin og hold port 80 på den interne routen. Bruk Wallabag-innstillingen riktig: sett domenenavnet til den endelige HTTPS-URL-en. For Wallabag beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en Wallabag-oppgradering testes?

Gjenopprett den aktuelle Wallabag-tilstanden i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi Wallabag-migreringer, parseroppførsel og worker-konfigurasjon bør testes mot representative lagrede sider. Behold det forrige Wallabag-imaget til grensen for datamigrering og rollback er forstått.