Jak hostować Wallabag samodzielnie w 2026 roku: importy, baza danych i zadania w tle

Najkrótsza demonstracja Wallabag potwierdza, że proces nasłuchuje na porcie 80. Produkcja wymaga mocniejszych dowodów. Usługa musi przejść ten scenariusz nawet po zastąpieniu kontenera: zapisać zwykły artykuł i problematyczną stronę, uruchomić pobieranie w tle, zsynchronizować klienta mobilnego i wyszukać zarchiwizowane treści.

Wallabag wdraża się w konkretnym celu: jako archiwum do późniejszego czytania, które usuwa zbędne elementy stron. Najczęstsza pułapka wdrożeniowa polega na tym, że assety lub przekierowania logowania używają HTTP, ponieważ zmienna domeny jest nieprawidłowa. Dlatego obsługa publicznego URL-a i trwały stan wymagają takiej samej uwagi jak uruchomienie obrazu.

Zmień lokalne polecenie w usługę, którą można kontrolować

Poniższe polecenie uwidacznia granicę kontenera, nie udając przy tym, że konfiguruje każdą zewnętrzną usługę.

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

Przed otwarciem ingressu sprawdź rozwiązaną konfigurację środowiska, mounty i listener. Dodaj sprawdzone ustawienia połączeń dla Postgres lub MariaDB, Redis oraz workerów zaplanowanych importów; w przypadku prywatnych usług używaj prywatnych nazw. Pomyślne uruchomienie kończy się dopiero wtedy, gdy możesz zapisać zwykły artykuł i problematyczną stronę, uruchomić pobieranie w tle, zsynchronizować klienta mobilnego i wyszukać zarchiwizowane treści — nie wtedy, gdy docker ps wyświetla Up.

Od czego zależy Wallabag

Wyznacz wokół Wallabag trzy granice: ingress do portu 80, trwały stan oraz wymagania pomocnicze. Kontener można zastąpić, ale pozostałe dwa obszary wymagają jasno określonych właścicieli. Kontrakt sieciowy Wallabag obejmuje Postgres lub MariaDB, Redis oraz workery zaplanowanych importów. Prywatne endpointy trzymaj w wewnętrznym DNS, zezwalaj tylko na wymagane połączenia wychodzące i nadaj Wallabagowi poświadczenia serwisowe o ograniczonym zakresie.

Diagram jest kompletny, gdy czysty klient może zapisać zwykły artykuł i problematyczną stronę, uruchomić pobieranie w tle, zsynchronizować klienta mobilnego i wyszukać zarchiwizowane treści. Zbieraj dane o czasie i zasobach dla pobierania stron, pracy parsera, pobierania obrazów, kolejek oraz wzrostu bazy danych. Jeśli transakcja się nie powiedzie, pierwsza granica, która nie działa zgodnie z dokumentacją, wskazuje, czy należy zbadać routing, lokalną przepustowość czy usługę pomocniczą.

Zabezpiecz Wallabag po bootstrapie

Nie przenoś założeń bezpieczeństwa z lokalnego tutoriala. Specyficzne zagrożenie w przypadku Wallabag polega na pozostawieniu domyślnych poświadczeń lub pominięciu konfiguracji zaufanego proxy. Dlatego środowisko produkcyjne powinno usunąć domyślne poświadczenia, chronić tokeny importu i skonfigurować zaufane proxy przed udostępnieniem czytnika.

SYMFONY__ENV__DOMAIN_NAME to konfiguracja, a nie sekret; zachowaj jawną wartość tej zmiennej, chroniąc jednocześnie oddzielne poświadczenia używane przez Wallabag. Ogranicz dostęp do systemu plików i sieci, zabezpiecz endpointy konfiguracji oraz określ limity uploadu, requestów i czasu wykonywania dla pobierania stron, pracy parsera, pobierania obrazów, kolejek i wzrostu bazy danych.

Ujednoznacznij publiczny origin

Udostępnij Wallabag pod jednym hostem HTTPS, a surowy port 80 pozostaw prywatny. Ustaw nazwę domeny na finalny URL HTTPS. Dzięki temu przeglądarki i klienci API nie poznają dwóch konkurencyjnych adresów.

Z czystego klienta uruchom znaną, poprawną transakcję i sprawdź pierwsze żądanie, które zakończyło się błędem. Skorzystaj z przewodnika po własnej domenie, gdy problem dotyczy DNS lub TLS. Traktuj komunikat „assety lub przekierowania logowania używają HTTP, ponieważ zmienna domeny jest nieprawidłowa” jako osobną diagnozę aplikacji dopiero po potwierdzeniu poprawności trasy.

Oddziel kontenery, które można zastąpić, od trwałych danych

Zestaw danych niezbędnych do odtworzenia obejmuje bazę danych, obrazy, zaimportowane treści i konfigurację. Zamontuj /var/www/wallabag/data przed bootstrapem, zapisz nieszkodliwe dane testowe i zastąp kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Volume chroni dane przed zastąpieniem kontenera, ale nie przed utratą hosta, przypadkowym usunięciem ani uszkodzeniem na poziomie aplikacji.

Wykonuj backupy z uwzględnieniem źródła danych: w razie potrzeby używaj logical dumpów działających baz danych, a pliki kopiuj wyłącznie ze spójnego stanu. Przechowuj jedną zaszyfrowaną kopię poza hostem Wallabag. Kryterium akceptacji odtworzenia musi być konkretne — artykuły, tagi, adnotacje, użytkownicy i tokeny API mają wrócić, a klient mobilny ma się zsynchronizować. Przewodnik po backupach przetestowanych przez odtworzenie wyjaśnia, dlaczego sam sukces joba nie jest wystarczający.

Zbierz dowody przed uruchomieniem Wallabag

W przypadku Wallabag zdefiniuj znaną, poprawną transakcję jeszcze przed uruchomieniem: zapisz zwykły artykuł i problematyczną stronę, uruchom pobieranie w tle, zsynchronizuj klienta mobilnego i wyszukaj zarchiwizowane treści. Umieść jej wymagania wstępne, oczekiwaną odpowiedź i kroki czyszczenia w systemie kontroli wersji, bez wartości sekretów. Przypnij obraz użyty do ustanowienia tego punktu odniesienia.

Użyj transakcji do sprawdzenia zastąpienia usługi oraz niezależnego odtworzenia. Odtworzona usługa jest akceptowalna tylko wtedy, gdy artykuły, tagi, adnotacje, użytkownicy i tokeny API wrócą, a klient mobilny się zsynchronizuje. Jednocześnie obserwuj pobieranie stron, pracę parsera, pobieranie obrazów, kolejki i wzrost bazy danych, a najwolniejszy lub najbardziej ograniczony element przekształć w alert na poziomie usługi.

Bramka jakości musi obejmować także przypadek negatywny: tymczasowo odbierz testowej tożsamości dostęp do Postgres lub MariaDB, Redis oraz workerów zaplanowanych importów. Potwierdź, że Wallabag generuje możliwy do wykorzystania komunikat o błędzie, zachowując dane, przywróć poprawny stan i ponownie wykonaj znaną, poprawną transakcję. Zachowanie obu wyników zapobiega temu, by powierzchowny endpoint health stał się jedynym dowodem gotowości produkcyjnej.

Obsługuj Wallabag z uwzględnieniem rzeczywistego wąskiego gardła

Zbuduj dashboardy wokół pobierania stron, pracy parsera, pobierania obrazów, kolejek i wzrostu bazy danych. Wykres CPU bez kontekstu tego obciążenia nie wyjaśni, dlaczego Wallabag działa wolno. Dodaj synthetic check lub zaplanowane sprawdzenie, które przy użyciu nieszkodliwych danych testowych próbuje zapisać zwykły artykuł i problematyczną stronę, uruchomić pobieranie w tle, zsynchronizować klienta mobilnego i wyszukać zarchiwizowane treści.

Przed aktualizacją uwzględnij zagrożenie specyficzne dla tej aplikacji: migracje Wallabag, zachowanie parsera i konfigurację workerów należy testować na reprezentatywnych zapisanych stronach. Odtwórz najnowszy backup w odizolowanym wdrożeniu, uruchom tam migracje i porównaj działanie. Jeśli assety lub przekierowania logowania używają HTTP, ponieważ zmienna domeny jest nieprawidłowa, zbadaj właściwą granicę — publiczny origin, storage lub zależność — zanim zmienisz niezwiązane ustawienia.

Użyj Dockup dla warstwy platformy

W przypadku Wallabag Dockup może utworzyć trasę i certyfikat TLS, zachować mounty, dostarczyć sekrety oraz umieścić Postgres lub MariaDB, Redis i workery zaplanowanych importów w prywatnej sieci, wdrażając usługę w Dockup lub na dołączonych serwerach.

Bramka wydania nadal obejmuje konkretną transakcję Wallabag: zapisanie zwykłego artykułu i problematycznej strony, uruchomienie pobierania w tle, synchronizację klienta mobilnego i wyszukanie zarchiwizowanych treści. Sprawdź także warunek odtworzenia — artykuły, tagi, adnotacje, użytkownicy i tokeny API mają wrócić, a klient mobilny ma się zsynchronizować. Te dwa sprawdzenia pokazują, czy wdrożenie działa i czy można je odtworzyć.

Najczęściej zadawane pytania

Czego Wallabag potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener Wallabag na port 80 przez jeden origin HTTPS. Wymagania sieciowe obejmują Postgres lub MariaDB, Redis oraz workery zaplanowanych importów. Nie uznawaj Wallabag za gotowy, dopóki nie możesz zapisać zwykłego artykułu i problematycznej strony, uruchomić pobierania w tle, zsynchronizować klienta mobilnego i wyszukać zarchiwizowane treści.

Które dane Wallabag powinny znaleźć się w backupie?

Utrwal /var/www/wallabag/data i uwzględnij bazę danych, obrazy, zaimportowane treści oraz konfigurację w tym samym manifeście odtworzenia. Czyste odtworzenie Wallabag kończy się powodzeniem tylko wtedy, gdy artykuły, tagi, adnotacje, użytkownicy i tokeny API wrócą, a klient mobilny się zsynchronizuje.

Czy Wallabag wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Wallabag, a port 80 pozostaw na trasie wewnętrznej. Zastosuj poprawnie ustawienie Wallabag: ustaw nazwę domeny na finalny URL HTTPS. W przypadku Wallabag HTTPS chroni poświadczenia i treści użytkowników podczas transmisji oraz zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Wallabag?

Odtwórz bieżący stan Wallabag w odizolowanym wdrożeniu, zastosuj wersję kandydującą i ponownie wykonaj transakcję akceptacyjną. Zwróć szczególną uwagę na to, że migracje Wallabag, zachowanie parsera i konfigurację workerów należy testować na reprezentatywnych zapisanych stronach. Zachowaj poprzedni obraz Wallabag do czasu zrozumienia granicy migracji danych i rollbacku.