Autor: Matt Connor 2026-07-15 · Zaktualizowano 2026-07-24

Instalacja Vaultwarden na VPS przez Docker

Q: Czy HTTPS jest niezbędny, czy można używać http w sieci LAN?

HTTPS jest wymagany w każdym przypadku poza testem localhost. Web vault oraz rozszerzenia Bitwarden wykorzystują przeglądarkowe Web Crypto API, które działa wyłącznie w bezpiecznym kontekście. Przez zwykłe http klient zwraca błąd Cannot read properties of undefined i nie pozwala na logowanie. Jedyny działający adres http to http://localhost, dlatego test przywracania w Kroku 8 wykorzystuje tunel SSH.

Q: Jak zablokować rejestrację obcych osób na moim serwerze?

Należy ustawić SIGNUPS_ALLOWED: "false" w pliku Compose i uruchomić docker compose up -d natychmiast po założeniu własnego konta. Następnie należy dodawać nowe osoby za pomocą przycisku Invite User w /admin. Wymaga to skonfigurowanego SMTP, aby użytkownicy otrzymali link zapraszający. Należy okresowo sprawdzać listę użytkowników administratora, aby upewnić się, że nie pojawiły się nieoczekiwane konta.

Dowiedz się, jak samodzielnie hostować Vaultwarden na VPS. Poznaj konfigurację Docker, wymagania TLS oraz metody zabezpieczania danych i backupu wolumenu.

Cel projektu

Menedżer haseł w pełnej kontroli użytkownika: Vaultwarden działający w jednym kontenerze za reverse proxy obsługującym HTTPS, z oficjalnymi aplikacjami Bitwarden na telefonie, laptopie oraz w przeglądarce. Vaultwarden implementuje API serwera Bitwarden w języku Rust i używa tego samego protokołu co bitwarden.com, dzięki czemu wszystkie oficjalne klienty działają bez zmian. Rozwiązanie to zajmuje około 100 MB RAM, w przeciwieństwie do oficjalnego stosu wymagającego wielu kontenerów.

Proces instalacji to kilkanaście linii w pliku Compose. Kluczowe aspekty, których nieprawidłowa konfiguracja powoduje błędy, to: konieczność posiadania certyfikatu TLS przed pierwszym uruchomieniem web vault, konieczność wyłączenia publicznej rejestracji po utworzeniu własnego konta oraz konieczność regularnego backupu i testowego przywracania wolumenu danych, ponieważ zawiera on wszystkie zapisane hasła.

Wymagania wstępne i istotne utrudnienia

Serwer VPS z zainstalowanymi Docker Engine oraz pluginem Compose. Zalecany system to świeża instalacja Ubuntu 24.04 KVM z uprawnieniami root lub sudo. 512 MB RAM jest wystarczające; 1 GB zapewnia pełen komfort. Jest to jedno z najlżejszych rozwiązań — znajduje się na szczycie listy usług wartych self-hostingu.
Domena z rekordem A (oraz AAAA w przypadku IPv6) wskazującym na vault.example.com serwer VPS. Certyfikat TLS jest wystawiany dla tej konkretnej nazwy, zatem DNS musi działać przed rozpoczęciem konfiguracji.
Otwarte porty 80 i 443 dla internetu, obsługiwane przez reverse proxy — nigdy bezpośrednio przez Vaultwarden. Port 80 służy wyłącznie do wyzwania ACME oraz przekierowania HTTP na HTTPS.
Najważniejsze utrudnienie na wstępie: klienci Bitwarden nie nawiążą połączenia z serwerem, który nie używa protokołu HTTPS. Nie można przeprowadzić testów przez HTTP — ta metoda nie działa z konkretnego powodu opisanego w kolejnej sekcji.

Dlaczego Vaultwarden, a nie oficjalny stos Bitwarden

Te same klienci, ułamek obciążenia. Oficjalny, samoobsługowy Bitwarden jest dostarczany jako zestaw kontenerów (MSSQL, Nginx, Identity, Api, Admin i inne) i wymaga około 2 GB RAM. Vaultwarden to pojedynczy plik binarny, który domyślnie przechowuje wszystkie dane w bazie SQLite i w stanie spoczynku zużywa zaledwie kilkadziesiąt megabajtów. Dla jednej osoby, rodziny lub małego zespołu jest to oczywisty wybór. Dzięki wiernej implementacji API Bitwarden, dane pozostają przenoszalne między Vaultwarden a bitwarden.com.

Rezygnuje się z większości funkcji klasy enterprise: brak provisioningu SCIM (choć eksperymentalne OpenID Connect SSO wprowadzono w wersji 1.35.0). Użytkownik pełni rolę operatora, co oznacza, że aktualizowanie, HTTPS oraz tworzenie kopii zapasowych leży po jego stronie. Niniejszy poradnik obejmuje te trzy obszary.

Dlaczego HTTPS nie jest opcjonalne

Bitwarden web vault oraz rozszerzenia przeglądarkowe generują klucze szyfrujące w przeglądarce przy użyciu Web Crypto API (window.crypto.subtle). Przeglądarki udostępniają crypto.subtle wyłącznie w secure context — poprzez HTTPS lub specjalny przypadek http://localhost. Przez zwykły http://vault.example.com jest to undefined, więc w momencie generowania klucza przez aplikację występuje błąd, a konsola wyświetla:

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

Strona przestaje odpowiadać lub wyświetla ogólny błąd kryptograficzny, co uniemożliwia logowanie. Klienci desktop, mobile oraz browser wykonują własną weryfikację adresu URL hostowanego samodzielnie. W przypadku adresu http (lub adresu nieosiągalnego) klient przerywa działanie z komunikatem:

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

W obu przypadkach przyczyną jest brak poprawnego HTTPS. Należy zatem najpierw skonfigurować TLS i nigdy nie otwierać sejfu przez http, nawet jednorazowo w celu szybkiego podglądu.

Krok 1 — DNS i reverse proxy (najpierw TLS)

Należy skierować rekord na adres VPS i potwierdzić, że rozwiązuje się on na właściwy adres:

dig +short vault.example.com

Wyświetlona linia musi zawierać adres IP serwera VPS. Jeśli linia jest pusta lub zawiera błędny adres, należy poprawić konfigurację DNS i odczekać na wygaśnięcie czasu TTL — wystawienie certyfikatu nie powróci, jeśli nazwa nie rozwiązuje się poprawnie.

Dla frontendu HTTPS niniejszy poradnik wykorzystuje Traefik, który automatycznie wystawia i odnawia certyfikaty Let's Encrypt oraz integruje się z Compose. Jeśli Traefik nie jest jeszcze uruchomiony, należy najpierw wykonać konfigurację reverse proxy Traefik i automatycznego TLS; proces ten tworzy zewnętrzną sieć Docker (proxy poniżej) oraz resolver ACME (letsencrypt), do którego podłączana jest usługa Vaultwarden. Standardowy nginx z ręcznie wystawionym certyfikatem działa identycznie z punktu widzenia Vaultwarden.

Wolisz nginx i Certbot zamiast Traefik? Należy umieścić Vaultwarden na 127.0.0.1:8080 (dodać ports: ["127.0.0.1:8080:80"] do usługi i usunąć etykiety Traefik), a następnie wystawić certyfikat i skonfigurować 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 upgrade na ścieżce 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";
    }
}

Należy zwrócić uwagę na linię X-Real-IP — to ona umożliwia usłudze Fail2ban późniejsze wykrycie rzeczywistego napastnika zamiast 127.0.0.1. Pozostałe elementy tego poradnika pozostają identyczne, niezależnie od tego, czy przodem stoi Traefik, czy nginx.

Step 2 — plik Compose

Najpierw należy utworzyć katalog projektu. W niniejszym poradniku używany jest /opt/vaultwarden, co zapewnia przewidywalną nazwę projektu Compose, a tym samym nazwę wolumenu danych vaultwarden_vw-data. Kroki dotyczące Fail2ban oraz kopii zapasowych zależą od tej konkretnej nazwy.

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

Należy utworzyć .env dla sekretu administratora oraz plik Compose w tym katalogu.

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

Token należy wygenerować za pomocą openssl rand -base64 48 i wkleić do pliku. (W kolejnym kroku omówione zostanie silniejsze haszowanie; na początek wystarczy długi, losowy ciąg znaków.)

# 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

Cała architektura opiera się na dwóch elementach tego pliku. Nie stosuje się mapowania ports:, zatem Vaultwarden jest dostępny wyłącznie poprzez Traefik i jego TLS — publikowanie portu na hoście powoduje przypadkowe udostępnianie sejfu przez protokół http. Dodatkowo DOMAIN musi być pełnym, publicznym adresem URL HTTPS: adres ten jest zaszyty w linkach do załączników, WebAuthn 2FA oraz punkcie końcowym powiadomień, więc błędna wartość lub protokół http spowoduje ich awarię, mimo poprawnego ładowania strony. Tag latest stanowi celowe odstępstwo od standardowej zasady never-latest — Vaultwarden dostarcza stabilne wersje jako pojedynczy obraz typu rolling, natomiast :testing służy jako oddzielny kanał wersji pre-release — należy zatem celowo aktualizować obraz i zapoznać się z listą zmian przed wykonaniem polecenia pull.

Należy uruchomić usługę i monitorować logi:

docker compose up -d
docker compose logs -f vaultwarden

Poprawne uruchomienie kończy się linią typu Rocket has launched from http://0.0.0.0:80. Należy odczekać kilka sekund, aż Traefik pobierze certyfikat, a następnie załadować https://vault.example.com — wirtualny sejf Bitwarden powinien zostać wyświetlony z poprawną ikoną kłódki i bez ostrzeżeń dotyczących certyfikatu.

Krok 3 — silny ADMIN_TOKEN oraz pułapka $$

ADMIN_TOKEN chroni /admin, czyli panel umożliwiający odczyt danych każdego użytkownika oraz wszystkich ustawień instancji, dlatego należy traktować go jak hasło root. Dopuszczalne są dwie formy.

Prosta forma to losowy ciąg znaków wygenerowany wcześniej za pomocą openssl rand -base64 48. Ponieważ format base64 nigdy nie zawiera znaku $, ciąg ten można bezpośrednio umieścić w .env bez konieczności stosowania znaków ucieczki.

Wzmocniona forma to skrót Argon2 PHC, dzięki czemu tekst jawny tokenu nie jest przechowywany na dysku. Należy wygenerować go z tego samego obrazu:

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

Program prosi o dwukrotne wprowadzenie danych i wyświetla ciąg zaczynający się od $argon2id$v=19$.... Następuje tutaj błąd, który powoduje godzinę przestoju: Docker Compose traktuje $ jako interpolację zmiennych, dlatego po wklejeniu skrótu do pliku Compose należy podwoić każdy znak $ na $$. Skrót należy umieścić bezpośrednio pod environment:, a nie poprzez .env, i nie należy go objąć cudzysłowem:

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

Pozostawienie pojedynczych znaków $ spowoduje ostrzeżenie The "argon2id" variable is not set i wyczyszczenie tokenu, przez co /admin odrzuci poprawne hasło. Należy uruchomić docker compose up -d, a tekst jawny wpisany podczas interakcji należy zapisać w własnym menedżerze haseł.

Krok 4 — rejestracja konta, a następnie blokada dostępu

W programie SIGNUPS_ALLOWED: "true" otwórz https://vault.example.com, kliknij Create account, a następnie zarejestruj się przy użyciu adresu e-mail oraz silnego hasła głównego. Hasła głównego nie można odzyskać — nie istnieje opcja resetowania — dlatego należy najpierw zapisać je w bezpiecznym miejscu.

Następnie należy zablokować dostęp. Edytuj plik Compose, aby wyłączyć rejestrację nowych użytkowników:

      SIGNUPS_ALLOWED: "false"

Zastosuj zmiany ponownie za pomocą docker compose up -d. Działanie to nie jest krytycznym procesem wzmacniania zabezpieczeń i można je odroczyć. Jeśli rejestracja pozostanie włączona, każda osoba, która trafi na adres URL — w tym boty indeksujące — może założyć konto na serwerze. Użytkownicy ci nie mają dostępu do zawartości skarbca, jednak zużywają zasoby i zmieniają prywatną instancję w usługę publiczną. Objawem pozostawienia włączonej rejestracji jest lista kont widoczna w /admin, które nie zostały utworzone przez administratora.

Aby dodać członków rodziny lub współpracowników w późniejszym terminie bez ponownego włączania publicznej rejestracji, należy użyć przycisku Invite User w /admin. Wymaga to poprawnej konfiguracji SMTP, aby zaproszona osoba otrzymała link.

Step 5 — dostęp do /admin

Przejdź do https://vault.example.com/admin i wprowadź token admin w postaci tekstowej (losowy ciąg znaków lub hasło przed zahashowaniem — nie sam hash). W panelu można wyświetlać listę użytkowników, konfigurować ustawienia, wysyłać testowe wiadomości e-mail oraz wykonywać migawki bazy danych.

Jeśli strona zwraca 404 Not Found, oznacza to, że ADMIN_TOKEN jest puste lub nieustawione, co całkowicie wyłącza panel — jest to dopuszczalne rozwiązanie, jeśli panel nie jest wymagany. Jeśli strona się ładuje, ale odrzuca token, sprawdź problem z ucieczką znaków (escaping trap) w $$ na poniższej liście błędów. Zapomniano tokenu? Nie ma procedury odzyskiwania; należy edytować .env lub plik Compose, ustawić nowy token i docker compose up -d.

Krok 6 — połączenie klientów Bitwarden

Każdy oficjalny klient może łączyć się z serwerem self-hosted. Należy zainstalować aplikację Bitwarden na komputer, urządzenie mobilne lub rozszerzenie do przeglądarki ze standardowych sklepów. Nie jest wymagana specjalna wersja Vaultwarden.

Przed zalogowaniem należy kliknąć ikonę ustawień na ekranie logowania (oznaczoną 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 zarejestrowanego adresu e-mail oraz hasła głównego. Klient powinien natychmiast nawiązać połączenie i umożliwić automatyczne wypełnianie oraz zapisywanie 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żyto protokołu http lub certyfikat jest niewiarygodny. Należy najpierw sprawdzić, czy adres https://vault.example.com ładuje się poprawnie w przeglądarce. Opóźnienia w aktualizacji danych na innych urządzeniach wynikają z działania mechanizmu WebSocket push, co opisano poniżej.

Step 7 — jail Fail2ban dla punktu końcowego logowania

Vaultwarden rejestruje każde nieudane logowanie w pliku określonym przez LOG_FILE — jest to niezbędne do ochrony przed atakami brute-force. Jeśli usługa Fail2ban nie jest jeszcze zainstalowana, instrukcję instalacji oraz podstawy konfiguracji znajduje się w przewodniku po utwardzaniu SSH za pomocą Fail2ban; tutaj dodaje się jedną jail dla skarbca.

Najpierw należy ustalić lokalizację wolumenu typu named na hoście, aby Fail2ban mógł odczytać logi:

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

Wynikiem będzie ścieżka typu /var/lib/docker/volumes/vaultwarden_vw-data/_data; log znajduje się w vaultwarden.log wewnątrz tej ścieżki. 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

Należy przeładować konfigurację za pomocą sudo systemctl restart fail2ban i potwierdzić za pomocą sudo fail2ban-client status vaultwarden.

O skuteczności ochrony decydują trzy szczegóły dotyczące Docker. Po pierwsze, jeśli logi wskazują IP: 127.0.0.1 lub adres proxy przy każdej nieudanej próbie, Vaultwarden zablokuje proxy — należy ustawić IP_HEADER na nagłówek przesyłany przez proxy (X-Forwarded-For dla Traefik, X-Real-IP dla powyższego bloku nginx, CF-Connecting-IP w przypadku Cloudflare). Po drugie, wybór odpowiedniego łańcucha iptables zależy od proxy: w przypadku Traefik działającego jako kontener z opublikowanymi portami, ruch przechodzi przez ścieżkę FORWARD w Dockerze, więc blokada musi znajdować się w DOCKER-USER jak powyżej; jeśli jednak wybrano opcję host-nginx ze Step 1, połączenia kończą się w nginx na łańcuchu INPUT hosta, a blokada DOCKER-USER ich nie wykryje — w takim przypadku należy usunąć linię chain = DOCKER-USER, aby Fail2ban używał domyślnego łańcucha INPUT. Po trzecie, należy użyć banaction = iptables-allports zamiast domyślnej blokady opartej na porcie — ta jail nie definiuje portu, a blokada wszystkich portów w DOCKER-USER skutecznie odcina sprawcę od wszystkich usług opublikowanych na maszynie.

Step 8 — wykonaj kopię zapasową skarbca, a następnie przeprowadź odzyskiwanie danych

Wolumen vw-data stanowi menedżer haseł. Zawiera on db.sqlite3 (wszystkie wpisy), katalogi attachments/ oraz sends/, pliki rsa_key.* służące do podpisywania sesji logowania oraz config.json z panelu administracyjnego. Kopia zapasowa pomijająca którykolwiek z tych elementów nie zadziała w razie awarii.

Kopiowanie db.sqlite3 podczas zapisu danych przez Vaultwarden może skutkować powstaniem uszkodzonego pliku. Należy wykonać migawkę typu cold snapshot — czas niedostępności usługi wynosi 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

Zaleca się uruchamianie tego procesu co noc za pomocą cron i przesyłanie .tgz poza serwer — kopia zapasowa przechowywana wyłącznie na chronionym serwerze nie spełnia definicji kopii zapasowej. Najlepszą metodą jest nocny backup restic na inny serwer lub object storage, który zapewnia szyfrowanie archiwum oraz deduplikację powtarzających się migawek. Przycisk Backup Database w panelu administracyjnym tworzy szybką kopię pliku SQLite, lecz nie obejmuje załączników ani kluczy.

Następnie należy przeprowadzić proces weryfikacji — należy raz odzyskać dane, aby potwierdzić poprawność kopii:

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 należy nawiązać tunel za pomocą ssh -L 8888:127.0.0.1:8888 you@your-vps i otworzyć http://localhost:8888. Ponieważ localhost stanowi bezpieczny kontekst, crypto.subtle jest dostępny, a szyfrowanie skarbca działa przez protokół http — jest to jedyne dopuszczalne miejsce. Należy zalogować się hasłem głównym i sprawdzić obecność wpisów: jeśli są obecne, baza danych, klucze RSA oraz hasło główne zostały poprawnie przetworzone, co umożliwia odbudowę systemu na nowym VPS w kilka minut. Należy zatrzymać kontener za pomocą Ctrl-C i usunąć /tmp/vw-restore.

Tryby awarii i widoczne komunikaty

Cannot read properties of undefined (reading 'importKey') w konsoli przeglądarki. Skarbiec został załadowany przez protokół http, przez co crypto.subtle jest niezdefiniowane; należy uzyskać do niego dostęp wyłącznie przez https:// i skonfigurować przekierowanie HTTP-to-HTTPS na proxy.

This is not a recognized Bitwarden server... w kliencie. Adres Server URL jest błędny (użyto http) lub certyfikat jest niewiarygodny; należy sprawdzić, czy https://vault.example.com wyświetla ikonę zamkniętej kłódki, a następnie ponownie wprowadzić adres w ustawieniach self-hosted klienta.

/admin odrzuca poprawne hasło. Hash Argon2 utracił znaki ucieczki — każdy $ musi być $$ w Compose — lub wprowadzono hash zamiast tekstu jawnego.

Powolna synchronizacja między urządzeniami; konsola wyświetla WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Proxy nie przekazuje nagłówków Upgrade/Connection; Traefik obsługuje to automatycznie, natomiast nginx wymaga dwóch linii upgrade z Kroku 1. Skarbiec nadal działa, synchronizacja następuje przy otwieraniu. Port 3012 został usunięty w wersji v1.31.0, więc osobna trasa WebSocket nie jest wymagana.

Fail2ban raportuje blokadę, ale napastnik nadal nawiązuje połączenia. System blokuje 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.

Upgrades

Pobierz nową wersję obrazu i utwórz kontener ponownie; nazwany volume oraz wszystkie dane pozostaną nienaruszone:

docker compose pull
docker compose up -d

Vaultwarden wydaje częste aktualizacje. Zaleca się śledzenie notatek wydawniczych projektu zamiast blokowania konkretnej wersji patch, ponieważ niektóre wydania zawierają instrukcje dotyczące migracji. Przed każdą znaczącą aktualizacją należy wykonać pełną kopię zapasową; przywrócenie stanu systemu jest możliwe poprzez wczytanie pliku tar do nowego volume.

FAQ

Czy Vaultwarden to to samo co Bitwarden?

Jest to kompatybilny, niezależny serwer, a nie oficjalna wersja. 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 znacznie mniej zasobów niż oficjalny stos technologiczny. Format skarbca jest identyczny, co umożliwia migrację w obu kierunkach poprzez eksport i import.

Czy HTTPS jest niezbędny, czy można używać http w sieci LAN?

HTTPS jest wymagany w każdym przypadku poza testem localhost. Web vault oraz rozszerzenia Bitwarden wykorzystują przeglądarkowe Web Crypto API, które działa wyłącznie w bezpiecznym kontekście. Przez zwykłe http klient zwraca błąd Cannot read properties of undefined i nie pozwala na logowanie. Jedyny działający adres http to http://localhost, dlatego test przywracania w Kroku 8 wykorzystuje tunel SSH.

Jak zablokować rejestrację obcych osób na moim serwerze?

Należy ustawić SIGNUPS_ALLOWED: "false" w pliku Compose i uruchomić docker compose up -d natychmiast po założeniu własnego konta. Następnie należy dodawać nowe osoby za pomocą przycisku Invite User w /admin. Wymaga to skonfigurowanego SMTP, aby użytkownicy otrzymali link zapraszający. Należy okresowo sprawdzać listę użytkowników administratora, aby upewnić się, że nie pojawiły się nieoczekiwane konta.

Jak wykonać kopię zapasową skarbca Vaultwarden?

Należy na chwilę zatrzymać kontener i zarchiwizować cały wolumen vw-data — pliki db.sqlite3, attachments/, sends/, config.json oraz rsa_key.* — a następnie skopiować archiwum poza serwer, najlepiej za pomocą nocnego zadania cron. Kopiowanie aktywnego pliku SQLite podczas pracy serwera grozi uszkodzeniem migawki, dlatego należy wykonywać kopię w trybie offline. Kluczowe jest, aby raz przeprowadzić test przywracania w tymczasowym kontenerze i się zalogować, aby potwierdzić poprawność kopii przed jej faktycznym wykorzystaniem.

Czy samodzielne hostowanie haseł jest bezpieczne?

Tak, pod warunkiem wykonania trzech czynności opisanych w tym poradniku: wdrożenia pełnego HTTPS, zablokowania rejestracji oraz ustawienia silnego tokenu administratora oraz przetestowania kopii zapasowych. Skarbiec jest szyfrowany po stronie klienta za pomocą hasła głównego, więc serwer nigdy nie widzi haseł w postaci jawnej — skradziony db.sqlite3 jest bezużyteczny bez hasła. Odpowiedzialność za aktualizacje i kopie zapasowe spoczywa na użytkowniku, dlatego narzędzie Fail2ban oraz procedury przywracania są w tym przypadku obowiązkowe.

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