Autor: Matt Connor 2026-07-15 · Zaktualizowano 2026-08-28

Jak zainstalować Vaultwarden na VPS z Dockerem

Q: Czy naprawdę potrzebuję HTTPS, czy mogę uruchomić usługę przez http w sieci lokalnej?

HTTPS jest wymagany w każdym przypadku poza testem localhost. Webowy sejf Bitwarden oraz rozszerzenia korzystają z przeglądarkowego API Web Crypto, które jest dostępne wyłącznie w bezpiecznym kontekście. W przypadku zwykłego połączenia http klient zgłasza błąd Cannot read properties of undefined i nie loguje się. Jedynym adresem http, który działa, jest http://localhost, dlatego test przywracania w kroku 8 wykorzystuje tunel SSH.

Q: Jak zablokować możliwość rejestracji obcym osobom na moim serwerze?

Ustaw SIGNUPS_ALLOWED: "false" w pliku Compose i uruchom docker compose up -d natychmiast po utworzeniu własnego konta. Od tego momentu dodawaj nowe osoby za pomocą przycisku Invite User w /admin, co wymaga skonfigurowanego SMTP, aby użytkownicy otrzymali link z zaproszeniem. Okresowo sprawdzaj listę użytkowników administratora, aby upewnić się, że nie pojawiły się nieoczekiwane konta.

Instrukcja konfiguracji Vaultwarden na własnym serwerze VPS. Dowiedz się jak poprawnie wdrożyć kontener, zabezpieczyć dostęp przez HTTPS oraz wdrożyć procedurę backupu danych.

Co budujesz

Menedżer haseł, którego jesteś pełnym właścicielem: Vaultwarden działający w jednym małym kontenerze za reverse proxy, które kończy połączenie HTTPS, z oficjalnymi aplikacjami Bitwarden na telefonie, laptopie i w przeglądarce skierowanymi na ten serwer. Vaultwarden implementuje API serwera Bitwarden w języku Rust i obsługuje ten sam protokół co bitwarden.com, dzięki czemu każdy oficjalny klient współpracuje z nim bez zmian, zajmując przy tym około 100 MB pamięci RAM zamiast wielokontenerowego stosu oficjalnego.

Sama instalacja to kilkanaście linii w pliku Compose. Trzy kwestie, które mają kluczowe znaczenie i najczęściej ulegają awarii, to: TLS musi zostać skonfigurowany przed pierwszym załadowaniem web vault, publiczna rejestracja musi zostać zamknięta natychmiast po utworzeniu własnego konta, a wolumen z danymi musi być regularnie kopiowany i testowo przywracany, ponieważ ten jeden katalog przechowuje wszystkie Twoje hasła.

Wymagania wstępne i istotne pułapki

Serwer VPS z zainstalowanym Docker Engine oraz wtyczką Compose, działający na czystym systemie Ubuntu 24.04 KVM z dostępem root lub sudo. 512 MB pamięci RAM jest wartością wystarczającą; 1 GB zapewnia komfort pracy. Jest to jedno z najlżejszych rozwiązań, które można uruchomić, znajdujące się w czołówce listy usług wartych samodzielnego hostowania. Należy jednak dobrać parametry serwera pod kątem innych współdzielonych usług: uruchomienie własnej biblioteki zdjęć, takiej jak PhotoPrism lub Immich na tym samym VPS podnosi zapotrzebowanie na pamięć RAM do poziomu kilku gigabajtów, podczas gdy Vaultwarden zużywa jej znikome ilości. Ta sama zasada dotyczy interfejsów multimedialnych dodawanych w późniejszym czasie, ponieważ przekształcenie biblioteki Jellyfin w wirtualną wypożyczalnię kaset z lat 90. oznacza kolejny stale działający kontener oraz konieczność zapewnienia zapasu mocy na transkodowanie w ramach tego samego budżetu zasobów.
Domena z rekordem A (oraz AAAA, jeśli dostępny jest IPv6) wskazującym vault.example.com na adres IP serwera VPS. Certyfikat TLS jest wystawiany dla konkretnej nazwy, dlatego konfiguracja DNS musi być poprawna przed rozpoczęciem prac.
Porty 80 oraz 443 otwarte na świat i obsługiwane przez reverse proxy, a nigdy bezpośrednio przez Vaultwarden. Port 80 jest wykorzystywany wyłącznie do weryfikacji wyzwania ACME dla certyfikatu oraz przekierowania z HTTP na HTTPS.
Najważniejsza pułapka na wstępie: klienci Bitwarden odmawiają połączenia z serwerem, który nie korzysta z HTTPS. Nie istnieje możliwość "przetestowania połączenia przez HTTP", ta ścieżka nie zadziała z konkretnych powodów omówionych w dalszej części.

Dlaczego Vaultwarden, a nie oficjalny stos Bitwarden

Te same klienty, ułamek obciążenia. Oficjalny, samodzielnie hostowany Bitwarden jest dostarczany jako zestaw kontenerów (MSSQL, Nginx, Identity, Api, Admin i inne) i wymaga około 2 GB pamięci RAM. Vaultwarden to pojedynczy plik binarny, który domyślnie przechowuje wszystkie dane w bazie SQLite i w stanie spoczynku zużywa kilkadziesiąt megabajtów pamięci. Dla jednej osoby, rodziny lub małego zespołu jest to oczywisty wybór, a ponieważ wiernie implementuje API Bitwarden, dane pozostają przenośne między nim a bitwarden.com.

Rezygnujesz z większości funkcji korporacyjnych: brak obsługi SCIM (choć eksperymentalne SSO OpenID Connect pojawiło się w wersji 1.35.0), a jako operator odpowiadasz za aktualizacje, HTTPS i kopie zapasowe. Ten przewodnik opisuje właśnie te trzy zadania.

Dlaczego HTTPS nie jest opcjonalny

Sejf internetowy Bitwarden oraz rozszerzenia przeglądarkowe wyprowadzają klucze szyfrujące w przeglądarce przy użyciu Web Crypto API (window.crypto.subtle). Przeglądarki udostępniają crypto.subtle wyłącznie w bezpiecznym kontekście (secure context), czyli przez HTTPS lub w szczególnym przypadku http://localhost. W przypadku zwykłego http://vault.example.com interfejs jest undefined, więc w momencie wyprowadzenia klucza przez aplikację następuje błąd, a w konsoli pojawia się:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Strona zawiesza się lub wyświetla ogólny błąd kryptograficzny i logowanie nie dochodzi do skutku. Klienci desktopowi, mobilni oraz przeglądarkowi przeprowadzają własną weryfikację adresu URL instancji self-hosted. W przypadku punktu końcowego http (lub nieosiągalnego) odmawiają połączenia z komunikatem:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Oba przypadki mają tę samą przyczynę: brak poprawnego HTTPS. Dlatego najpierw konfigurujemy TLS i nigdy nie otwieramy sejfu przez http, nawet jednorazowo w celu szybkiego sprawdzenia.

Krok 1, DNS i reverse proxy (najpierw TLS)

Skieruj rekord na swój VPS i potwierdź, że rozwiązuje się on do właściwego adresu:

dig +short vault.example.com

Wyświetlona linia musi zawierać adres IP Twojego VPS. Jeśli jest pusta lub błędna, popraw konfigurację DNS i odczekaj czas TTL; wystawianie certyfikatu nie powiedzie się dla nazwy, która nie jest poprawnie rozwiązywana.

Dla frontendu HTTPS w tym przewodniku wykorzystano Traefik, który automatycznie wystawia i odnawia certyfikaty Let's Encrypt oraz integruje się bezpośrednio z Compose. Jeśli jeszcze go nie używasz, wykonaj najpierw konfigurację Traefik jako reverse proxy z automatycznym TLS; tworzy ona zewnętrzną sieć Docker (proxy poniżej) oraz resolver ACME (letsencrypt), do których podłącza się usługa Vaultwarden. Zwykły nginx z ręcznie wystawionym certyfikatem działa z perspektywy Vaultwarden identycznie.

Wolisz nginx i Certbot zamiast Traefik? Umieść Vaultwarden na 127.0.0.1:8080 (dodaj ports: ["127.0.0.1:8080:80"] do usługi i usuń etykiety Traefik), a następnie wystaw certyfikat i skonfiguruj proxy. Część dotycząca certyfikatów została opisana w wystawianiu certyfikatów Let's Encrypt za pomocą Certbot i nginx. Kluczowym dodatkiem jest obsługa WebSocket dla ścieżki powiadomień:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Zwróć uwagę na linię X-Real-IP; pozwala ona Fail2ban na późniejszą identyfikację rzeczywistego atakującego zamiast 127.0.0.1. Cała reszta tego przewodnika jest identyczna, niezależnie od tego, czy przed usługą znajduje się Traefik, czy nginx.

Krok 2, plik Compose

Najpierw utwórz katalog projektu. Niniejszy przewodnik wykorzystuje /opt/vaultwarden, co sprawia, że nazwa projektu Compose, a tym samym wolumen danych vaultwarden_vw-data, są przewidywalne; kroki dotyczące Fail2ban oraz kopii zapasowych opisane poniżej zależą od tej konkretnej nazwy.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Utwórz plik .env dla sekretu administratora oraz plik Compose w tym katalogu.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Wygeneruj ten token za pomocą openssl rand -base64 48 i wklej go. (Silniejsza forma haszowana zostanie omówiona w dalszej części; długi, losowy ciąg znaków jest wystarczający na początek).

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Dwie kwestie w tym pliku stanowią o całym projekcie. Brak mapowania ports: oznacza, że Vaultwarden jest dostępny wyłącznie przez Traefik i jego TLS; publikowanie portu na hoście jest przyczyną, dla której użytkownicy przypadkowo udostępniają vault przez http. Z kolei DOMAIN musi być pełnym publicznym adresem URL HTTPS: jest on wpisany w linki do załączników, WebAuthn 2FA oraz punkt końcowy powiadomień, więc błędna lub nieprawidłowa wartość http powoduje ich niedziałanie, nawet jeśli strona się ładuje. Znacznik latest jest celowym wyjątkiem od standardowej zasady unikania latest; Vaultwarden wydaje swoje stabilne wersje jako pojedynczy, ciągły obraz, przy czym :testing stanowi oddzielny kanał wersji przedpremierowych, dlatego aktualizuj celowo i przejrzyj informacje o wydaniu przed pobraniem obrazu. Ten wyjątek jest jednak wąski: większość długo działających kontenerów lepiej przypiąć do konkretnego znacznika, co zapewnia przewidywalność agenta działającego stale na tym samym VPS po restartach i pobraniach obrazów.

Uruchom usługę i monitoruj dziennik:

docker compose up -d
docker compose logs -f vaultwarden

Poprawny start kończy się linią taką jak Rocket has launched from http://0.0.0.0:80. Odczekaj kilka sekund, aż Traefik pobierze certyfikat, a następnie załaduj https://vault.example.com; powinieneś zobaczyć web vault Bitwarden z poprawną ikoną kłódki i bez ostrzeżeń o certyfikacie.

Krok 3, silny ADMIN_TOKEN i pułapka związana z $$

ADMIN_TOKEN zabezpiecza /admin, panel umożliwiający odczyt wszystkich użytkowników i ustawień instancji, dlatego należy go traktować jak hasło użytkownika root. Dostępne są dwie formy zabezpieczenia.

Prostszą formą jest losowy ciąg znaków wygenerowany wcześniej za pomocą openssl rand -base64 48. Ponieważ format base64 nigdy nie zawiera $, można go bezpośrednio wkleić do .env bez konieczności stosowania znaków ucieczki.

Forma wzmocniona to skrót Argon2 PHC, dzięki któremu hasło w postaci jawnej nigdy nie jest zapisywane na dysku. Wygeneruj go przy użyciu tego samego obrazu:

docker run --rm -it vaultwarden/server /vaultwarden hash --preset owasp

Narzędzie poprosi o dwukrotne wprowadzenie hasła i wyświetli ciąg znaków zaczynający się od $argon2id$v=19$.... Oto pułapka, która kosztuje użytkowników mnóstwo czasu: Docker Compose traktuje $ jako interpolację zmiennych, dlatego podczas wklejania skrótu do pliku Compose należy podwoić każdy znak $ na $$. Umieść go bezpośrednio pod environment:, nie używając .env, i nie otaczaj go cudzysłowami:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Jeśli pozostawisz pojedyncze znaki $, Docker Compose wyświetli ostrzeżenie The "argon2id" variable is not set i wyczyści wartość tokena, przez co /admin odrzuci poprawne hasło. Uruchom docker compose up -d i przechowuj hasło w postaci jawnej, wpisane podczas monitu, we własnym menedżerze haseł.

Krok 4, rejestracja konta i zabezpieczenie dostępu

Używając SIGNUPS_ALLOWED: "true", otwórz https://vault.example.com, kliknij Create account i zarejestruj się, podając adres e-mail oraz silne hasło główne. Tego hasła nie da się odzyskać, nie istnieje procedura jego resetowania, dlatego w pierwszej kolejności zapisz je w trwałym miejscu.

Teraz zamknij dostęp. Edytuj plik Compose, aby wyłączyć rejestrację:

      SIGNUPS_ALLOWED: "false"

Zastosuj zmiany za pomocą docker compose up -d. To nie jest zabezpieczenie, które można odłożyć w czasie. Pozostawienie otwartej rejestracji sprawia, że każdy, kto znajdzie adres URL – a roboty indeksujące z pewnością go znajdą – może utworzyć konto na Twoim serwerze. Osoby te nie uzyskają dostępu do Twojego sejfu, ale zużyją zasoby i przekształcą Twoją prywatną instancję w otwartą usługę. Sygnałem, że rejestracja pozostała włączona, jest /admin, gdzie pojawią się konta, których nie utworzyłeś.

Aby dodać członków rodziny lub współpracowników w późniejszym czasie bez ponownego otwierania publicznej rejestracji, użyj przycisku Invite User w /admin. Ta ścieżka wymaga skonfigurowanego SMTP, aby zaproszona osoba otrzymała swój link.

Krok 5, uzyskiwanie dostępu do /admin

Przejdź pod adres https://vault.example.com/admin i wprowadź tekstowy token administratora (losowy ciąg znaków lub hasło, które zostało zahaszowane; nie należy wprowadzać samego hasha). Wewnątrz panelu można wyświetlić listę użytkowników, dostosować ustawienia, wysłać testową wiadomość e-mail oraz wykonać migawkę bazy danych.

Jeśli strona zwraca błąd 404 Not Found, oznacza to, że zmienna ADMIN_TOKEN jest pusta lub nieustawiona, co całkowicie wyłącza panel (jest to poprawne rozwiązanie, jeśli panel nie jest potrzebny). Jeśli strona się ładuje, ale odrzuca token, należy zapoznać się z pułapką dotyczącą znaków ucieczki $$ w poniższej liście błędów. Zapomniano tokena? Nie ma opcji odzyskiwania; należy edytować plik .env lub plik Compose, ustawić nowy token i wykonać docker compose up -d.

Krok 6, połączenie klientów Bitwarden

Każdy oficjalny klient może łączyć się z własnym serwerem, dlatego należy zainstalować wersję desktopową, mobilną lub rozszerzenie przeglądarkowe Bitwarden z oficjalnych sklepów. Nie jest wymagana specjalna kompilacja Vaultwarden.

Przed zalogowaniem należy otworzyć ustawienia (ikona koła zębatego) na ekranie logowania (oznaczone jako Self-hosted lub Region → Self-hosted), ustawić Server URL na https://vault.example.com i zapisać zmiany. Następnie należy zalogować się przy użyciu adresu e-mail oraz hasła głównego użytego podczas rejestracji. Klient powinien nawiązać połączenie i zaoferować funkcje autouzupełniania oraz zapisywania danych uwierzytelniających.

Jeśli klient wyświetla błąd This is not a recognized Bitwarden server. You may need to check with your provider or update your server., oznacza to, że adres URL jest błędny, używa protokołu http lub certyfikat jest niezaufany. Należy najpierw sprawdzić w przeglądarce, czy adres https://vault.example.com ładuje się poprawnie. Opóźnienia w synchronizacji na innych urządzeniach wynikają z działania mechanizmu WebSocket push, który opisano poniżej.

Krok 7, jail Fail2ban dla punktu końcowego logowania

Vaultwarden zapisuje każdą nieudaną próbę logowania do pliku określonego przez LOG_FILE, co stanowi idealne źródło danych dla mechanizmu ochrony przed atakami typu brute-force. Jeśli Fail2ban nie jest jeszcze uruchomiony, instrukcję instalacji i podstawowej konfiguracji można znaleźć w przewodniku zabezpieczania SSH za pomocą Fail2ban; w tym miejscu dodamy jeden jail przeznaczony dla Vaultwarden.

Najpierw należy zlokalizować ścieżkę wolumenu nazwanego na hoście, aby Fail2ban mógł odczytać dziennik:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Polecenie to wyświetli ścieżkę podobną do /var/lib/docker/volumes/vaultwarden_vw-data/_data; plik dziennika znajduje się wewnątrz niej pod nazwą vaultwarden.log. Należy utworzyć filtr:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Oraz jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Przeładuj konfigurację za pomocą sudo systemctl restart fail2ban i sprawdź status za pomocą sudo fail2ban-client status vaultwarden.

Trzy szczegóły dotyczące Docker decydują o skuteczności tej ochrony. Po pierwsze, jeśli dziennik wskazuje IP: 127.0.0.1 lub adres IP proxy przy każdej nieudanej próbie, Vaultwarden blokuje adres proxy. Należy ustawić IP_HEADER na nagłówek faktycznie przesyłany przez proxy (X-Forwarded-For dla Traefik, X-Real-IP dla powyższego bloku nginx, CF-Connecting-IP w przypadku korzystania z Cloudflare). Po drugie, odpowiedni łańcuch iptables zależy od używanego proxy: jeśli Traefik działa jako kontener z opublikowanymi portami, ruch przechodzi przez ścieżkę FORWARD w Docker, więc blokada musi znajdować się w łańcuchu DOCKER-USER, jak pokazano powyżej. Jeśli jednak wybrano opcję host-nginx z Kroku 1, połączenia kończą się na łańcuchu INPUT hosta, a blokada DOCKER-USER ich nie przechwyci; w takim przypadku należy usunąć linię chain = DOCKER-USER, aby Fail2ban użył domyślnego łańcucha INPUT. Po trzecie, należy użyć banaction = iptables-allports zamiast domyślnego ustawienia opartego na portach. Ten jail nie definiuje portu, a blokada wszystkich portów w DOCKER-USER skutecznie odcina sprawcę od każdej usługi opublikowanej na serwerze.

Krok 8, wykonanie kopii zapasowej skarbca, a następnie jego przywrócenie

Wolumen vw-data jest Twoim menedżerem haseł. Przechowuje on db.sqlite3 (każdy wpis), katalogi attachments/ i sends/, pliki rsa_key.* podpisujące sesje logowania oraz config.json z panelu administratora. Kopia zapasowa pomijająca którykolwiek z tych elementów zawiedzie w momencie, gdy będzie potrzebna.

Kopiowanie db.sqlite3 w trakcie zapisu przez Vaultwarden może skutkować przechwyceniem niekompletnego, uszkodzonego pliku, dlatego należy wykonać „zimną” migawkę (cold snapshot); czas przestoju wynosi zaledwie kilka sekund:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Uruchamiaj to zadanie przez cron każdej nocy i kopiuj .tgz poza serwer; kopia zapasowa znajdująca się wyłącznie na zabezpieczanym serwerze nie jest kopią zapasową. Poprawnym sposobem przesyłania danych jest nocna kopia zapasowa restic na inny serwer lub pamięć obiektową, która szyfruje archiwum i deduplikuje powtarzające się migawki. Przycisk Backup Database w panelu administratora to wygodna „gorąca” migawka samego pliku SQLite, ale pomija ona załączniki oraz klucze.

Teraz rytuał, który odróżnia realną kopię zapasową od pobożnych życzeń: przywróć ją raz i sprawdź, czy działa:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Z poziomu laptopa utwórz tunel za pomocą ssh -L 8888:127.0.0.1:8888 you@your-vps i otwórz http://localhost:8888. Ponieważ localhost stanowi bezpieczny kontekst, crypto.subtle jest dostępny, a skarbiec deszyfruje się tutaj przez zwykłe http – jest to jedyne miejsce, w którym jest to dozwolone. Zaloguj się głównym hasłem i potwierdź obecność wpisów: jeśli są widoczne, oznacza to, że baza danych, klucze RSA oraz hasło główne działają poprawnie, a Ty możesz odtworzyć usługę na nowym VPS w kilka minut. Zatrzymaj kontener za pomocą Ctrl-C i usuń /tmp/vw-restore. Utrzymuj nawyk używania tuneli dla każdego innego interfejsu administracyjnego na serwerze, który nigdy nie powinien być wystawiony na działanie Internetu; w ten sam sposób uzyskasz dostęp do samodzielnie hostowanego skanera bezpieczeństwa open-kritt na porcie 5173.

Tryby awarii i towarzyszące im komunikaty

Cannot read properties of undefined (reading 'importKey') w konsoli przeglądarki. Magazyn został załadowany przez http, więc crypto.subtle jest niezdefiniowane; należy łączyć się wyłącznie przez https:// i dodać przekierowanie HTTP na HTTPS na poziomie proxy.

This is not a recognized Bitwarden server... w kliencie. Adres Server URL jest podany przez http, zawiera literówkę lub certyfikat jest niezaufany; należy upewnić się, że https://vault.example.com wyświetla poprawną ikonę kłódki, a następnie ponownie wprowadzić adres w ustawieniach self-hosted klienta.

/admin odrzuca poprawne hasło. Skrót Argon2 utracił znaki ucieczki, każdy $ musi być zapisany jako $$ w pliku Compose, albo wprowadzono skrót zamiast tekstu jawnego, który on reprezentuje.

Powolna synchronizacja między urządzeniami; konsola pokazuje WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Proxy nie przekazuje nagłówków Upgrade/Connection; Traefik wykonuje to automatycznie, nginx wymaga dwóch linii upgrade z kroku 1. Magazyn nadal działa, ale synchronizacja odbywa się tylko przy otwarciu. Stary dedykowany port 3012 został usunięty w wersji v1.31.0, więc osobna trasa WebSocket nie jest już potrzebna.

Fail2ban zgłasza blokadę, ale atakujący nadal się łączy. Blokowana jest wartość 127.0.0.1, ponieważ IP_HEADER jest błędne lub blokada znajduje się w niewłaściwym łańcuchu iptables; należy ustawić chain = DOCKER-USER oraz banaction = iptables-allports.

Aktualizacje

Pobierz nowy obraz i odtwórz kontener; nazwany wolumen oraz wszystkie dane zostaną zachowane:

docker compose pull
docker compose up -d

Vaultwarden często publikuje nowe wersje. Monitoruj informacje o wydaniach projektu zamiast blokować wersję poprawki, ponieważ niektóre wydania zawierają instrukcje dotyczące migracji. Przed każdą dużą aktualizacją wykonaj kopię zapasową; powrót do poprzedniej wersji jest możliwy poprzez przywrócenie archiwum tar do nowego wolumenu.

FAQ

Czy Vaultwarden to to samo co Bitwarden?

Jest to kompatybilny, niezależny serwer, a nie oficjalne rozwiązanie. Vaultwarden implementuje API serwera Bitwarden w języku Rust, dzięki czemu oficjalne klienty desktopowe, mobilne, przeglądarkowe oraz CLI działają z nim poprawnie, zużywając ułamek zasobów oficjalnego stosu. Format sejfu jest identyczny, więc możliwa jest migracja w obu kierunkach poprzez eksport i import danych.

Czy naprawdę potrzebuję HTTPS, czy mogę uruchomić usługę przez http w sieci lokalnej?

HTTPS jest wymagany w każdym przypadku poza testem localhost. Webowy sejf Bitwarden oraz rozszerzenia korzystają z przeglądarkowego API Web Crypto, które jest dostępne wyłącznie w bezpiecznym kontekście. W przypadku zwykłego połączenia http klient zgłasza błąd Cannot read properties of undefined i nie loguje się. Jedynym adresem http, który działa, jest http://localhost, dlatego test przywracania w kroku 8 wykorzystuje tunel SSH.

Jak zablokować możliwość rejestracji obcym osobom na moim serwerze?

Ustaw SIGNUPS_ALLOWED: "false" w pliku Compose i uruchom docker compose up -d natychmiast po utworzeniu własnego konta. Od tego momentu dodawaj nowe osoby za pomocą przycisku Invite User w /admin, co wymaga skonfigurowanego SMTP, aby użytkownicy otrzymali link z zaproszeniem. Okresowo sprawdzaj listę użytkowników administratora, aby upewnić się, że nie pojawiły się nieoczekiwane konta.

Jak wykonać kopię zapasową sejfu Vaultwarden?

Zatrzymaj kontener na czas tworzenia kopii i zarchiwizuj cały wolumen vw-data, pliki db.sqlite3, attachments/, sends/, config.json oraz rsa_key.*, a następnie skopiuj archiwum poza serwer, najlepiej za pomocą zadania cron uruchamianego co noc. Kopiowanie aktywnego pliku SQLite podczas pracy serwera grozi uszkodzeniem migawki, dlatego należy to robić na wyłączonej usłudze. Co najważniejsze, przywróć kopię raz do tymczasowego kontenera i zaloguj się, aby mieć pewność, że backup jest poprawny, zanim zaczniesz na nim polegać.

Czy samodzielne hostowanie haseł jest bezpieczne?

Tak, pod warunkiem wykonania trzech czynności opisanych w tym przewodniku: wdrożenia rzeczywistego HTTPS, wyłączenia otwartej rejestracji wraz z silnym tokenem administratora oraz przetestowania kopii zapasowych. Sejf jest szyfrowany po stronie klienta za pomocą hasła głównego, więc nawet serwer nigdy nie widzi haseł w postaci jawnej, a skradziony plik db.sqlite3 jest bezużyteczny bez tego hasła. Ceną za to jest odpowiedzialność za aktualizacje i kopie zapasowe, dlatego Fail2ban oraz procedura przywracania danych nie są tutaj opcjonalne. Gdy te zabezpieczenia są już wdrożone, szczegółowa analiza potencjalnych wektorów ataku na własny sejf stanowi użyteczny kolejny krok, ponieważ przy wpisach szyfrowanych po stronie klienta, jedynymi elementami wymagającymi ochrony pozostają token administratora oraz archiwum kopii zapasowej.

#vaultwarden #passwords #security #docker #self-hosting