Hosting Vaultwarden na Managed VPS: Państwa hasła na Państwa serwerze

Co robi Vaultwarden

Vaultwarden to serwer do zarządzania hasłami napisany w Ruście, przeznaczony do samodzielnego hostingu. Jego wiki kieruje go do osób prywatnych, rodzin i organizacji o ludzkiej skali. Sejf webowy jest dostarczany w jego obrazach Docker.

Udostępnia API zgodne z oficjalnymi klientami Bitwarden w przeglądarce, na komputerze i na telefonie. README zaznacza, że projekt nie jest powiązany z Bitwarden ani z Bitwarden, Inc., i prosi o zgłaszanie wszelkich problemów bezpośrednio jemu, niezależnie od używanego klienta, a nie oficjalnym kanałom pomocy.

• Sejf: sejf osobisty, załączniki, ikony stron, osobisty klucz API oraz Send do przekazywania tekstu lub pliku.
• Organizacje: kolekcje, udostępnianie haseł, role, grupy, dzienniki zdarzeń i polityki.
• Uwierzytelnianie dwuskładnikowe: aplikacja uwierzytelniająca, e-mail, FIDO2 WebAuthn, YubiKey i Duo.
• Środki ratunkowe: dostęp awaryjny i odzyskiwanie konta, przy czym to drugie wymaga skonfigurowanego e-maila.
• Administracja: strona /admin z ustawieniami, kontami i diagnostyką.

Wiki wymienia też to, czego brakuje w porównaniu z serwerem oficjalnym, na przykład logowania kluczem dostępu, ról niestandardowych i niektórych polityk firmowych. Zaznacza, że funkcje przydatne głównie dużym organizacjom nie są priorytetem projektu: jeśli ich Państwo potrzebują, proszę przeczytać tę listę.

Na co pozwala licencja AGPL-3.0

Vaultwarden jest udostępniany na GNU Affero General Public License, wersja 3. Tekst potwierdza nieograniczone prawo do uruchamiania niezmodyfikowanego programu. Mogą więc Państwo używać obrazu opublikowanego przez projekt dla swojej firmy i zespołu, bez zakupu licencji.

Artykuł 13 dodaje warunek właściwy dla AGPL: jeśli Państwo zmodyfikują program, Państwa wersja musi oferować każdemu, kto korzysta z niej zdalnie, przez sieć, możliwość bezpłatnego uzyskania jej kodu źródłowego.

Instalacja przez Docker Compose

README zaleca obrazy kontenerów. Na serwerze z zainstalowanym Dockerem proszę utworzyć katalog i umieścić w nim ten compose.yaml, zaczerpnięty z README i wiki:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• Port opublikowany na 127.0.0.1: jak w README, Vaultwarden jest osiągalny wyłącznie przez odwrotne proxy, postawione na tym samym serwerze.
• DOMAIN: podstawowy adres Państwa instancji, w https. Wiki ostrzega, że bez tego przestają działać pewne funkcje, w tym załączniki i linki z zaproszeniami.
• Katalog vw-data na dysku lokalnym: przechowuje wszystkie dane. Wiki wskazuje kłopoty SQLite na woluminie CIFS lub Samba, który nie obsługuje blokad.
• Tag latest podąża za ostatnią opublikowaną wersją, a wiki poleca go w większości zastosowań. Tag taki jak 1.37.5 przypina wersję, a latest-alpine daje to samo na bazie Alpine.

Państwa nazwa domeny wskazuje na serwer rekordami A i AAAA, a odwiedzający docierają na porty 80 i 443. Dopóki odwrotne proxy nie jest uruchomione, sejf webowy pozostaje bezużyteczny: proszę przejść od razu do następnej sekcji.

Projekt nie podaje wymagań dotyczących pamięci ani procesora; przedstawia się jedynie jako rozwiązanie na przypadki, w których oficjalna usługa, wymagająca dużo zasobów, nie pasuje. Rozmiar zależy od liczby kont i objętości załączników. Na Managed VPS wystarczy opisać nam swoje zastosowanie, a polecimy odpowiedni rozmiar.

HTTPS i WebSocket: odwrotne proxy

Sejf webowy korzysta z API Web Crypto, które przeglądarki udostępniają tylko w kontekstach bezpiecznych: README podaje, że działa on dopiero po włączeniu HTTPS, a wiki uznaje HTTPS za „pretty much required”, czyli niemal obowiązkowy. Projekt zaleca odwrotne proxy przed Vaultwarden i odradza wbudowany TLS jego frameworka Rocket.

Proszę wybrać certyfikat uznawany powszechnie, jak te z Let’s Encrypt, które poleca wiki: przy certyfikacie samopodpisanym niektóre platformy odmawiają połączenia. Certyfikat musi zawierać pełny łańcuch, w przeciwnym razie urządzenia z Androidem się nie połączą.

Powiadomienia WebSocket, domyślnie włączone, informują przeglądarkę, aplikację na komputer i rozszerzenie, że wpis się zmienił. Przechodzą przez główny port HTTP, a proxy musi przekazywać nagłówki Upgrade i Connection. Aplikacje mobilne korzystają z natywnych powiadomień swojego systemu, które konfiguruje się osobno.

Z Caddy

Wiki radzi, by jeśli nie mają Państwo preferencji, spojrzeć najpierw na Caddy: sam włącza HTTPS, uzyskuje certyfikat Let’s Encrypt i obsługuje WebSocket. Ustawienie z wiki przekazuje też Vaultwarden rzeczywisty adres odwiedzającego, na potrzeby jego dzienników:

vault.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Z Nginx i Certbotem

Ten blok powtarza przykład Nginx z wiki, zredukowany do portu 80, aby Certbot mógł zainstalować HTTPS:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    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;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot następnie instaluje certyfikat i zajmuje się jego odnawianiem:

sudo certbot --nginx

Sprawdzenie WebSocket

Proszę otworzyć narzędzia deweloperskie przeglądarki, zakładkę sieci, filtr WS, a następnie ponownie połączyć się z sejfem: odpowiedź 101 na /notifications/hub potwierdza połączenie. Inny test z wiki: proszę otworzyć sejf w dwóch przeglądarkach, zmienić nazwę wpisu w jednej, a zmiana natychmiast pojawi się w drugiej.

Zamknięcie rejestracji

Domyślnie każdy, kto dotrze do Państwa instancji, może w niej utworzyć konto. Jest to przydatne dla pierwszego konta, a wiki zaleca potem zamknąć rejestrację, aby uniemożliwić atakującemu założenie własnego.

1. Proszę otworzyć swój adres HTTPS i utworzyć konto, a następnie połączyć swoje aplikacje z tym adresem.
2. Proszę zmienić SIGNUPS_ALLOWED na "false" w compose.yaml.
3. Proszę uruchomić ponownie poleceniem docker compose up -d: zmienna środowiskowa jest związana z kontenerem, który trzeba utworzyć na nowo, by ją uwzględnił.

SIGNUPS_ALLOWED: "false"

• Zaproszenia pozostają otwarte po zamknięciu rejestracji: właściciele i administratorzy organizacji mogą zapraszać nowe osoby. INVITATIONS_ALLOWED ustawione na "false" odbiera tę możliwość, a wiki zostawia ten wybór zależnie od zaufania do użytkowników.
• Lista domen: SIGNUPS_DOMAINS_WHITELIST ogranicza rejestrację do wybranych domen e-mail, a SIGNUPS_VERIFY ustawione na true wymusza wtedy weryfikację adresu. Gdy ta lista jest ustawiona, SIGNUPS_ALLOWED jest ignorowane.
• Strona administracji pozwala zaprosić każdego, niezależnie od tych ograniczeń.

Gdy tylko zapiszą Państwo konfigurację ze strony administracji, w katalogu z danymi powstaje plik config.json i ma on pierwszeństwo przed zmiennymi środowiskowymi. Dotyczące go ustawienia zmienia się wtedy z tej strony: edycja compose.yaml już nie wystarcza.

Strona administracji i jej token

Strona /admin służy do konfigurowania Vaultwarden, przeglądania i usuwania kont oraz organizacji, usuwania uwierzytelniania dwuskładnikowego użytkownika, zapraszania i czytania diagnostyki. Bez ADMIN_TOKEN pozostaje wyłączona: jeśli nie jest Państwu potrzebna, proszę ją tak zostawić.

Wiki gorąco zaleca włączenie HTTPS przed użyciem tej strony. Token pełni rolę hasła i można go przechowywać w postaci zahaszowanej, argon2id, zamiast jawnie w konfiguracji. Vaultwarden dostarcza do tego polecenie: dwukrotnie prosi o hasło, a następnie zwraca ciąg PHC.

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

Ten ciąg proszę umieścić w pliku .env, obok compose.yaml, w apostrofach, a następnie wywołać go z usługi:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Proszę sprawdzić wynik, uruchomić ponownie, a następnie zalogować się na /admin swoim hasłem, a nie ciągiem PHC:

docker compose config
docker compose up -d

• Sesja trwa domyślnie 20 minut, co reguluje ADMIN_SESSION_LIFETIME. Otwarta sesja pozostaje ważna po zmianie tokenu. Aby przerwać wszystkie, proszę usunąć rsa_key.pem z katalogu z danymi i zrestartować, co wyloguje także użytkowników i unieważni trwające zaproszenia.
• Ograniczony dostęp: przykłady proxy z wiki pokazują, jak otworzyć /admin tylko dla wybranych adresów albo dodać do niego uwierzytelnianie HTTP.
• DISABLE_ADMIN_TOKEN usuwa jakąkolwiek kontrolę: jest przewidziane dla odrębnej warstwy uwierzytelniania umieszczonej przed nim, a wiki zastrzega je dla tych, którzy wiedzą, co robią.

Co chroni sejf

Pierwszą ochroną jest hasło główne. Dane sejfu są szyfrowane kluczami osobistymi lub organizacji: kto zdobędzie kopię bazy albo przejmie sesję, musi jeszcze złamać to hasło, aby je odczytać. Najważniejsza jest więc jego siła. Sama sesja administracyjna pozwala usunąć konto lub odebrać uwierzytelnianie dwuskładnikowe, ale nie daje dostępu do danych sejfu.

Na zapomnienie hasła głównego proszę przygotować się, zanim do niego dojdzie: włączyć dostęp awaryjny swojego konta, a w organizacji odzyskiwanie konta, które wymaga skonfigurowanego e-maila.

Trzy dodatkowe ustawienia z przewodnika utwardzania

• Konto inne niż root: obraz domyślnie działa jako root, a wiki uważa za lepsze nadanie mu minimum uprawnień. Proszę dodać user: 1000:1000 do usługi, z katalogiem vw-data należącym do tego użytkownika.
• Dzienniki proxy: połączenie WebSocket przekazuje token w adresie, w access_token. Jeśli Państwa proxy przechowuje dzienniki albo wysyła je do usługi zewnętrznej, wiki zaleca ukrycie tej wartości.
• Minimum montowań: proszę montować katalog z danymi i nic więcej, ani katalogu domowego, ani /var/run/docker.sock.

SQLite, MariaDB czy PostgreSQL

Ten sam obraz obsługuje wszystkie trzy bazy. Wiki opisuje SQLite jako najczęściej używaną i najlepiej przetestowaną i poleca ją w większości zastosowań, chyba że jest konkretna potrzeba innej.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Proszę utworzyć pustą bazę i jej użytkownika: przy starcie Vaultwarden sam zakłada w niej swój schemat. Hasło ze znakami specjalnymi zapisuje się w tym adresie w kodowaniu procentowym.

Wyboru proszę dokonać, zanim sejf zostanie zapełniony. Wiki opisuje przejście z SQLite na PostgreSQL za pomocą pgloader, zaznaczając, że projekt nie wspiera tej drogi, że odbywa się to na Państwa ryzyko i że zaczyna się od kopii zapasowej.

E-maile: konfiguracja SMTP

Vaultwarden startuje bez e-maila, ale kilka funkcji od niego zależy: zaproszenia, weryfikacja adresów, wysyłanie podpowiedzi do hasła, uwierzytelnianie dwuskładnikowe e-mailem i odzyskiwanie konta.

Na VPS Simafri wysyłka odbywa się przez uwierzytelniony przekaźnik SMTP, na porcie 587: adres posiadanego już konta pocztowego albo Simafri Suite. Hasło umieszcza się w pliku .env, tak jak token administratora:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Linki z zaproszeniami są budowane na podstawie DOMAIN i pozostają ważne 5 dni.
• Microsoft: wiki podaje, że Hotmail, Outlook i Office 365 wymagają obecnie OAuth2, którego Vaultwarden jeszcze nie obsługuje. Błąd, po którym to poznać, to No compatible authentication mechanism was found.
• Gmail: według wiki proszę przewidzieć hasło aplikacji.
• Próba: strona administracji wysyła testowego e-maila. Jeśli zmieniają tam Państwo ustawienie SMTP, proszę najpierw zapisać, bo test korzysta z zapisanych ustawień, a ten zapis tworzy config.json.

Jeśli nic nie wychodzi, wiki proponuje przetestować połączenie z przekaźnikiem z serwera. Polecenie zwraca 0, gdy przekaźnik odpowiada:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Kopie zapasowe

README przypomina, że projekt nie ponosi odpowiedzialności za utratę danych, i gorąco zaleca regularne kopie zapasowe. Wiki radzi, by były automatyczne, z co najmniej jedną kopią w innym miejscu. Oto, co zawiera katalog z danymi przy SQLite:

Baza, przy działającej usłudze

Od wersji 1.32.1 Vaultwarden potrafi sam wykonać kopię swojej bazy SQLite, bez zatrzymywania usługi:

docker exec -it vaultwarden /vaultwarden backup

Polecenie zapisuje plik db_AAAAMMJJ_HHMMSS.sqlite3 obok bazy, w vw-data. Obraz nie zawiera ani sqlite3, ani cron: wiki radzi zaplanować zadanie na serwerze, co najmniej raz dziennie. Wtedy proszę usunąć -it, ponieważ zadanie cykliczne nie ma terminala, i porządkować te pliki, które się gromadzą.

Cały katalog, przy zatrzymanej usłudze

Gdy baza nie jest używana, wystarczy zwykła kopia wszystkich jej plików. To metoda przy zatrzymanej usłudze, którą wiki podaje jako przykład dla Dockera, i obejmuje ona także załączniki:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

Wiki uważa warstwę szyfrowania za przydatną, zwłaszcza gdy kopia zawiera token administratora i dane dostępowe SMTP, i wymienia rclone, restic i rustic do wysyłania kopii w inne miejsce. Przy MariaDB lub PostgreSQL do katalogu vw-data proszę dodać eksport bazy.

Wiki prosi, by nie polegać wyłącznie na migawkach dysku, trudniejszych do przywrócenia. Proszę więc zachować te kopie właściwe aplikacji: umieszczone na dysku serwera, trafiają także do jego nocnych kopii zapasowych.

Przywracanie

1. Proszę zatrzymać Vaultwarden.
2. Proszę zastąpić każdy plik lub katalog w vw-data jego skopiowaną wersją.
3. Jeśli baza pochodzi z /vaultwarden backup, proszę nadać jej nazwę db.sqlite3 i najpierw usunąć każdy istniejący plik db.sqlite3-wal: niepasujący dziennik może uszkodzić bazę. Jeśli pochodzi z bezpośredniej kopii, proszę przywrócić razem db.sqlite3 i jego db.sqlite3-wal.
4. Proszę uruchomić ponownie i sprawdzić, czy da się otworzyć sejf.

Wiki radzi powtarzać to ćwiczenie od czasu do czasu, zachowując kopię danych na miejscu: w ten sposób sprawdzają Państwo, że kopia zapasowa działa.

Aktualizacje

Wiki podaje dwa polecenia, wydawane z katalogu z compose.yaml. Katalog z danymi pozostaje na miejscu:

docker compose pull
docker compose up -d

Te aktualizacje liczą się bardziej niż gdzie indziej. Aplikacje mobilne i rozszerzenia przeglądarek aktualizują się same, a wiki ostrzega, że różnica wersji względem serwera może powodować nagłe awarie. Sejf webowy, dostarczany w obrazie, zawsze pozostaje dopasowany do swojego serwera.

Projekt nie ma kalendarza wydań: proszę śledzić jego informacje o wydaniach i wykonać kopię zapasową tuż przed każdą aktualizacją. Niektóre zawierają poprawki bezpieczeństwa, jak wersja 1.37.5 z 1 listopada 2026 roku, której notatki zalecają aktualizację jak najszybciej. Te same notatki ostrzegają również, że od wersji 1.37.5 nieprawidłowa wartość konfiguracji uniemożliwia uruchomienie Vaultwarden: proszę przejrzeć plik ze zmiennymi środowiskowymi przed aktualizacją. Strona diagnostyczna w /admin wskazuje, czy istnieje nowsza wersja.

Kto za co odpowiada na Managed VPS

Samodzielny hosting wymaga prowadzenia serwera, oprócz samej aplikacji. Na Managed VPS nasze zespoły przejmują serwer i proaktywnie czuwają nad Państwa instancją; Vaultwarden pozostaje Państwa oprogramowaniem, z Państwa ustawieniami i danymi.

Jeśli wolą Państwo, aby nasze zespoły interweniowały w samej aplikacji, usługa ta jest rozliczana godzinowo lub ryczałtowo, z wyceną przekazaną przed interwencją.