Instalacja Vaultwarden: własna instancja z HTTPS

Zakres i stan weryfikacji

Przykład dotyczy osobnego serwera czytelnika. Nie jest instalacją usługi na Vaultwarden.pl. Przykład obrazu zaktualizowano 07.11.2026 do Vaultwarden 1.37.5 na podstawie oficjalnej notatki wydania. Pozostała instrukcja opiera się na źródłach z 26.10.2026. Instrukcji nie uruchomiono w odizolowanym laboratorium Docker. Sprawdzono zgodność opisanych elementów z dokumentacją, co nie zastępuje testu wdrożenia.

Przyjmujemy Ubuntu Server 24.04 LTS amd64, system obsługiwany przez Docker Engine. Przykład wymaga wcześniej zainstalowanego Engine i wtyczki Compose zgodnie z tą dokumentacją. Nie podajemy niepotwierdzonego minimum RAM ani gwarantowanej pojemności; zaplanuj zasoby według liczby użytkowników, załączników i prób obciążenia.

Przygotuj domenę i środowisko

Potrzebujesz własnej domeny, kontroli DNS, aktualnego systemu, dostępu administracyjnego, trwałego dysku i kopii poza serwerem. Przykładowe vault.example.com zastąp rzeczywistą nazwą, a admin@example.com własnym adresem do ACME. Przed uruchomieniem upewnij się, że rekordy A i ewentualne AAAA wskazują właściwy serwer.

Wariant poniżej udostępnia publicznie tylko proxy Caddy na TCP 80 i 443. Sprawdź zajętość portów oraz reguły sieciowe; publikowane przez Docker porty mogą omijać reguły UFW. Nie otwieraj dodatkowo portu serwera Vaultwarden ani bazy. Prywatna instancja z DNS-01 wymaga innego wariantu konfiguracji.

Zapisz Compose i Caddyfile

Pracuj w osobnym katalogu projektu, z restrykcyjnym umask 0077. Utwórz compose.yaml:

services:
  vaultwarden:
    image: vaultwarden/server:1.37.5
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "false"
    volumes:
      - ./vw-data:/data
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config

Serwer i proxy komunikują się w sieci Compose. Brak ports w usłudze vaultwarden jest celowy. caddy:2 to ruchomy tag pomocniczego proxy z przykładu wiki, nie zamrożone wydanie. Przed rzeczywistym wdrożeniem wybierz i zapisz sprawdzony tag lub digest Caddy oraz digest Vaultwarden. Nie używaj testing jako stabilnej ścieżki.

W tym samym katalogu utwórz Caddyfile:

vault.example.com {
    tls admin@example.com
    reverse_proxy vaultwarden:80
}

Caddy pozyskuje certyfikat przez ACME; wymaga poprawnego DNS i dostępu do portów. Nie włączamy logowania pełnych URL-i, które mogą zawierać tokeny. Web vault korzysta z Web Crypto i wymaga bezpiecznego kontekstu. Nie obchodź błędów HTTPS. Powiadomienia WebSocket przechodzą głównym portem HTTP Vaultwarden, bez historycznego portu 3012.

Zweryfikuj i uruchom

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps

Sprawdź logi lokalnie, unikając publikacji sekretów. Otwórz wyłącznie własny adres HTTPS, sprawdź certyfikat i dostęp do web vault. ./vw-data jest trwałym katalogiem danych. Nie kasuj go podczas aktualizacji. W tym wariancie domyślną bazą jest SQLite. PostgreSQL i MariaDB są odrębnymi wariantami, wymagającymi osobnej konfiguracji i backupu bazy; nie korzystasz z bazy portalu Laravel.

Pierwsze konto i polityka rejestracji

Początkowo rejestracja i zaproszenia organizacji są wyłączone. Przed utworzeniem pierwszego konta ogranicz dostęp do instancji na poziomie sieci, np. do własnego adresu lub VPN. Dopiero w tym ograniczonym środowisku tymczasowo ustaw SIGNUPS_ALLOWED: "true", odtwórz usługę przez docker compose up -d vaultwarden i utwórz konto testowe. Następnie wróć do "false", ponownie odtwórz usługę i sprawdź odrzucenie nowej rejestracji.

Alternatywą jest zaproszenie z chronionego panelu instancji. Nie zostawiaj otwartej rejestracji podczas konfiguracji. SIGNUPS_ALLOWED i INVITATIONS_ALLOWED odpowiadają za różne ścieżki; sprawdź obie oraz ewentualną listę domen dopuszczonych do rejestracji.

Poczta i ochrona panelu

Skonfiguruj SMTP z parametrami otrzymanymi od operatora: SMTP_HOST, SMTP_FROM, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME i sekret przekazany przez SMTP_PASSWORD_FILE. Dla typowego submission stosuje się 587 i starttls, ale operator musi potwierdzić właściwy wariant. Umieść plik sekretu w kontrolowanym katalogu, zamontuj go tylko do odczytu i ustaw faktyczną ścieżkę kontenera. Nie zapisuj prawdziwego hasła w publicznym Compose. Wyślij wiadomość testową i zweryfikuj dostarczenie oraz URL instancji.

Panel administratora Vaultwarden jest domyślnie wyłączony w przykładzie. Jeśli go potrzebujesz, najpierw ogranicz dostęp sieciowo i przygotuj silny sekret. Wbudowane polecenie pyta o hasło bez podawania go jako argumentu:

docker compose exec vaultwarden /vaultwarden hash

Zapisz wynik PHC Argon2id jako chroniony sekret i użyj udokumentowanej opcji ADMIN_TOKEN_FILE ze ścieżką wewnątrz kontenera. Sprawdź prawa i odczyt przez proces. Nie ustawiaj DISABLE_ADMIN_TOKEN=true. W panelu logujesz się pierwotnym sekretem, nie ciągiem PHC. Jeśli umieszczasz PHC bezpośrednio w YAML, zasady escapowania $ Compose wymagają szczególnej uwagi — wariant plikowy ogranicza ten problem.

Panel /admin na Twojej domenie instancji nie jest panelem redakcyjnym naszego portalu. Ustawienia zapisane w config.json mogą nadpisywać środowisko; kontroluj komunikaty startowe i pierwszeństwo konfiguracji.

Kopia i próba odtworzenia

Dla niewielkiego wdrożenia SQLite zaplanuj okno bez zapisów. Zatrzymaj usługę vaultwarden, sprawdź poprawne zatrzymanie i wykonaj chronioną kopię całego vw-data wraz z istniejącymi plikami WAL oraz konfiguracji i sekretów przechowywanych poza nim. Uruchom usługę ponownie i sprawdź dostępność. Awaria zadania kopii musi wywołać powiadomienie; ręczna kopia nie jest kompletnym harmonogramem.

Backup obejmuje bazę, attachments, potrzebne sends, config.json, klucze rsa_key* i ustawienia poza katalogiem danych. Szyfruj kopie i przechowuj je również poza serwerem. Dla pracy online użyj mechanizmu backupu SQLite i skoordynuj spójność z plikami; kopiowanie samego aktywnego db.sqlite3 jest niewystarczające.

Odtwórz kopię w osobnym środowisku z tą samą wersją, wyłączoną pocztą i push. Nie nadpisuj działającego katalogu danych. Sprawdź logowanie, wpis, załącznik, kolekcję i synchronizację. Backup nie odzyskuje automatycznie zapomnianego hasła głównego. Zakres kopii i WAL.

Odbiór przed migracją haseł

Przetestuj web vault i konkretne wersje Bitwarden na używanych platformach. Na fikcyjnych danych sprawdź zapis, odczyt, autouzupełnianie, synchronizację, 2FA i odtwarzanie. Zapisz wyniki oraz numery wersji. W tym portalu nie deklarujemy wykonania tych testów klient–serwer.

Aktualizacja i wycofanie

Przeczytaj uwagi wydania, wykonaj spójną kopię i przeprowadź próbę w odizolowanym środowisku. Zmień wersję obrazu w Compose, pobierz go i odtwórz usługę. Migracje bazy mogą uniemożliwić uruchomienie starego serwera na nowych danych. Plan powrotu wymaga odtworzenia pasującej kopii danych i starego obrazu, z uwzględnieniem utraty zmian od czasu kopii. Nie uruchamiaj starego obrazu na zmigrowanej bazie bez potwierdzonego wsparcia.

Źródła uzupełniające: Compose w wiki, obrazy, panel, SMTP.