Come fare self-hosting di Wallabag nel 2026: importazioni, database e background job

La demo più semplice di Wallabag dimostra soltanto che un processo è in ascolto sulla porta 80. In produzione servono prove più solide. Il sistema deve superare questo scenario anche dopo la sostituzione del container: salvare un articolo normale e una pagina complessa, eseguire il recupero in background, sincronizzare un client mobile e cercare nei contenuti archiviati.

Wallabag viene distribuito con uno scopo preciso: creare un archivio read-it-later che elimini gli elementi superflui dalle pagine. Il problema di deployment più comune è che le risorse o i redirect di login usano HTTP perché la variabile del dominio è errata; per questo la gestione dell'URL pubblico e dello stato persistente richiede la stessa attenzione dell'avvio dell'immagine.

Trasforma il comando locale in un servizio ispezionabile

Il comando seguente rende visibile il confine del container senza fingere di predisporre ogni servizio esterno.

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

Prima di aprire l'ingress, controlla l'ambiente risolto, i mount e il listener. Aggiungi le impostazioni di connessione verificate per Postgres o MariaDB, Redis e i worker di importazione pianificati; usa nomi privati per i servizi privati. Un avvio riuscito si conclude quando puoi salvare un articolo normale e una pagina complessa, eseguire il recupero in background, sincronizzare un client mobile e cercare nei contenuti archiviati, non quando docker ps stampa Up.

Da cosa dipende Wallabag

Traccia tre confini intorno a Wallabag: ingress verso la porta 80, stato persistente e requisiti di supporto. Il container è sostituibile, ma gli altri due elementi richiedono responsabili espliciti. Il contratto di rete di Wallabag comprende Postgres o MariaDB, Redis e i worker di importazione pianificati. Mantieni gli endpoint privati sul DNS interno, consenti solo le chiamate in uscita necessarie e assegna a Wallabag credenziali di servizio con privilegi limitati.

Il diagramma è completo quando un client pulito può salvare un articolo normale e una pagina complessa, eseguire il recupero in background, sincronizzare un client mobile e cercare nei contenuti archiviati. Raccogli dati su tempi e risorse per il recupero delle pagine, l'elaborazione del parser, il download delle immagini, le code e la crescita del database. Se la transazione fallisce, il primo confine che non si comporta come documentato indica se devi analizzare il routing, la capacità locale o un servizio di supporto.

Metti in sicurezza Wallabag dopo il bootstrap

Non ereditare le ipotesi di sicurezza di un tutorial locale. Il problema specifico di Wallabag consiste nel lasciare le credenziali predefinite o nel saltare la configurazione del trusted proxy. In produzione devi quindi rimuovere le credenziali predefinite, proteggere i token di importazione e configurare i trusted proxy prima di esporre il reader.

SYMFONY__ENV__DOMAIN_NAME è una configurazione, non un secret; mantieni esplicito il suo valore proteggendo al contempo le credenziali separate utilizzate da Wallabag. Limita l'accesso al filesystem e alla rete, proteggi gli endpoint di setup e definisci limiti di upload, richiesta o esecuzione per il recupero delle pagine, l'elaborazione del parser, il download delle immagini, le code e la crescita del database.

Rendi inequivocabile l'origine pubblica

Esponi un unico hostname HTTPS per Wallabag e mantieni privata la porta 80 esposta direttamente. Imposta il nome del dominio sull'URL HTTPS finale. In questo modo impedisci ai browser e ai client API di scoprire due indirizzi in concorrenza.

Da un client pulito, esegui la transazione verificata e analizza la prima richiesta che fallisce. Usa la guida ai domini personalizzati quando il DNS o il TLS non sono corretti. Considera “le risorse o i redirect di login usano HTTP perché la variabile del dominio è errata” come una diagnosi applicativa separata, una volta verificato il percorso.

Separa i container sostituibili dai dati persistenti

Il set di dati necessario per il ripristino comprende database, immagini, contenuti importati e configurazione. Monta /var/www/wallabag/data prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è effettivamente persistente. Un volume protegge i dati dalla sostituzione del container, ma non dalla perdita dell'host, dalla cancellazione accidentale o dalla corruzione a livello applicativo.

Esegui backup che comprendano la natura della sorgente dati: usa logical dump per i database attivi quando necessario e copia i file solo da uno stato coerente. Conserva una copia cifrata lontano dall'host di Wallabag. Il criterio di accettazione per un ripristino è specifico: articoli, tag, annotazioni, utenti e token API devono tornare disponibili e il client mobile deve sincronizzarsi. La guida ai backup verificati con un ripristino spiega perché il solo esito positivo del job non è sufficiente.

Raccogli le prove prima di portare Wallabag in produzione

Per Wallabag, definisci una transazione verificata prima del lancio: salva un articolo normale e una pagina complessa, esegui il recupero in background, sincronizza un client mobile e cerca nei contenuti archiviati. Inserisci i prerequisiti, la risposta prevista e i passaggi di pulizia nel version control, senza valori segreti. Fissa la versione dell'immagine usata per stabilire questo riferimento.

Usa la transazione per convalidare una sostituzione e un ripristino indipendente. Il servizio ripristinato è accettabile solo quando articoli, tag, annotazioni, utenti e token API tornano disponibili e il client mobile si sincronizza. Nel frattempo, osserva il recupero delle pagine, l'elaborazione del parser, il download delle immagini, le code e la crescita del database, trasformando la parte più lenta o più vincolata in un alert di livello servizio.

Il gate deve includere anche un caso negativo: nega temporaneamente all'identità di test l'accesso a Postgres o MariaDB, Redis e ai worker di importazione pianificati. Verifica che Wallabag produca un errore utile preservando i dati, ripristina la condizione valida e ripeti la transazione verificata. Conservare entrambi i risultati impedisce che un endpoint di health superficiale diventi l'unica prova di funzionamento in produzione.

Gestisci Wallabag in base al suo vero collo di bottiglia

Crea dashboard incentrate sul recupero delle pagine, l'elaborazione del parser, il download delle immagini, le code e la crescita del database. Un grafico della CPU privo del contesto del carico di lavoro non può spiegare perché Wallabag è lento. Aggiungi un check sintetico o pianificato che provi a salvare un articolo normale e una pagina complessa, eseguire il recupero in background, sincronizzare un client mobile e cercare nei contenuti archiviati usando dati di test innocui.

Prima di un upgrade, considera questo rischio specifico dell'applicazione: le migration di Wallabag, il comportamento del parser e la configurazione dei worker devono essere testati con pagine salvate rappresentative. Ripristina un backup recente in un deployment isolato, esegui lì le migration e confronta il comportamento. Se le risorse o i redirect di login usano HTTP perché la variabile del dominio è errata, analizza il confine coinvolto — origine pubblica, storage o dipendenza — prima di modificare impostazioni non correlate.

Usa Dockup per il platform layer

Per Wallabag, Dockup può creare il route e il certificato TLS, conservare i mount, distribuire i secret e collocare Postgres o MariaDB, Redis e i worker di importazione pianificati su una rete privata, eseguendo il deployment su Dockup o su server collegati.

Il release gate resta comunque la transazione concreta di Wallabag: salva un articolo normale e una pagina complessa, esegui il recupero in background, sincronizza un client mobile e cerca nei contenuti archiviati. Verifica anche la condizione di ripristino: articoli, tag, annotazioni, utenti e token API devono tornare disponibili e il client mobile deve sincronizzarsi. Questi due controlli mostrano se il deployment funziona e se può essere ripristinato.

Domande frequenti

Di cosa ha bisogno Wallabag per un deployment in produzione?

Instrada il container di Wallabag sulla porta 80 attraverso un'unica origine HTTPS. Il requisito di rete di supporto comprende Postgres o MariaDB, Redis e i worker di importazione pianificati. Non considerare Wallabag pronto finché non puoi salvare un articolo normale e una pagina complessa, eseguire il recupero in background, sincronizzare un client mobile e cercare nei contenuti archiviati.

Quali dati di Wallabag devono essere inclusi in un backup?

Rendi persistente /var/www/wallabag/data e includi database, immagini, contenuti importati e configurazione nello stesso manifest di ripristino. Un ripristino pulito di Wallabag ha esito positivo solo quando articoli, tag, annotazioni, utenti e token API tornano disponibili e il client mobile si sincronizza.

Wallabag richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di Wallabag e mantieni la porta 80 sul percorso interno. Applica correttamente l'impostazione di Wallabag: imposta il nome del dominio sull'URL HTTPS finale. Per Wallabag, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento dei client sensibile all'origine.

Come si deve testare un upgrade di Wallabag?

Ripristina lo stato corrente di Wallabag in un deployment isolato, applica la versione candidata e ripeti la relativa transazione di accettazione. Presta particolare attenzione perché le migration di Wallabag, il comportamento del parser e la configurazione dei worker devono essere testati con pagine salvate rappresentative. Conserva la precedente immagine di Wallabag finché non avrai compreso i confini della migrazione dei dati e del rollback.