Jak samodzielnie hostować Vaultwarden w 2026 roku: domeny, SMTP i bezpieczne kopie zapasowe

Istnieją dwie wersje „uruchomienia Vaultwarden”: kontener działa albo usługa wykonuje swoje rzeczywiste zadanie. Znaczenie ma tylko ta druga opcja. Dowodem jest zalogowanie się z rozszerzenia przeglądarki, utworzenie elementu, synchronizacja drugiego klienta, przesłanie załącznika i pobranie elementu Send po restarcie.

Vaultwarden służy do tego jako kompaktowy serwer haseł zgodny z Bitwarden. Wdrożenie musi zachować elementy stojące za tym działaniem; port, volume i certyfikat to dane wejściowe, a nie rezultat.

Volume to dopiero pierwsza warstwa odzyskiwania

Trwały zestaw potrzebny do odzyskiwania obejmuje bazę danych, załączniki, elementy Send, klucze i konfigurację w /data. Zamontuj /data przed bootstrapem, zapisz niegroźne przykładowe dane 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.

Twórz kopie zapasowe z uwzględnieniem źródła danych: w razie potrzeby używaj logical dumpów dla działających baz danych, a pliki kopiuj wyłącznie ze spójnego stanu. Przechowuj jedną zaszyfrowaną kopię poza hostem Vaultwarden. Kryterium akceptacji przywracania jest konkretne — elementy sejfu, załączniki, elementy Send i członkostwo w organizacji muszą poprawnie synchronizować się z czystym klientem po przywróceniu. Przewodnik po kopiach zapasowych przetestowanych pod kątem przywracania wyjaśnia, dlaczego sam sukces zadania nie jest wystarczający.

Uruchom Vaultwarden bez ukrywania elementów składowych

Uruchom Vaultwarden tak, aby do czasu zakończenia bootstrapu trasa pozostawała prywatna.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Jeśli proces wpada w pętlę, porównaj oczekiwanego użytkownika obrazu z właścicielem każdej zamontowanej ścieżki. Jeśli kontener działa, przetestuj lokalnie port 80, a następnie od razu przejdź do workflow: zaloguj się z rozszerzenia przeglądarki, utwórz element, zsynchronizuj drugiego klienta, prześlij załącznik i pobierz element Send po restarcie. Przypnij wersję obrazu dopiero po pomyślnym zakończeniu tego testu end-to-end i zapisz dokładną konfigurację obok usługi.

Wyznacz granice środowiska uruchomieniowego Vaultwarden

Wyznacz trzy granice wokół Vaultwarden: ingress do portu 80, trwały stan i wymagania pomocnicze. Kontener można zastąpić, ale pozostałe dwa elementy wymagają jednoznacznie wskazanych właścicieli. Zewnętrznym wymaganiem Vaultwarden jest działający SMTP, jeśli potrzebne są zaproszenia i wiadomości dotyczące emergency access. Przetestuj wychodzący DNS, TLS i zachowanie providera bez publikowania kolejnej usługi przychodzącej.

Diagram jest kompletny, gdy czysty klient może zalogować się z rozszerzenia przeglądarki, utworzyć element, zsynchronizować drugiego klienta, przesłać załącznik i pobrać element Send po restarcie. Zbieraj dane o czasie działania i zasobach dotyczące rozmiaru załączników, rywalizacji o zapis w SQLite lub limitów puli połączeń z bazą danych oraz opóźnień SMTP podczas wysyłania zaproszeń. Jeśli transakcja się nie powiedzie, pierwsza granica, która nie działa zgodnie z dokumentacją, wskazuje, czy należy zbadać routing, lokalną wydajność czy usługę pomocniczą.

Rozróżniaj adresy URL wewnętrzne i zewnętrzne

Unikaj tymczasowych i stałych publicznych originów dla Vaultwarden. Zamiast tego ustaw DOMAIN na dokładny zewnętrzny origin HTTPS, skieruj wybraną nazwę DNS na trasę platformy i proxy’uj wyłącznie do portu 80.

Wykonaj tę czynność spoza hosta: zaloguj się z rozszerzenia przeglądarki, utwórz element, zsynchronizuj drugiego klienta, prześlij załącznik i pobierz element Send po restarcie. Jeśli ingress nie działa, przewodnik rozwiązywania problemów z błędem 502 opisuje pomyłki związane z portami i listenerami. Jeśli Vaultwarden otrzymuje żądanie, ale DOMAIN wskazuje HTTP, podczas gdy przeglądarka wymaga bezpiecznego originu dla funkcji sejfu, dowody wskazują już na problem poza proxy.

Produkcyjny test akceptacyjny dla Vaultwarden

Bramka produkcyjna dla Vaultwarden powinna być możliwa do wykonania przez osobę, która nie tworzyła wdrożenia. Przekaż jej przypiętą wersję, niewrażliwe konto testowe i następujące zadanie: zalogować się z rozszerzenia przeglądarki, utworzyć element, zsynchronizować drugiego klienta, przesłać załącznik i pobrać element Send po restarcie. Jeśli instrukcje wymagają nieudokumentowanego dostępu przez shell, usługa nie jest jeszcze gotowa operacyjnie.

Powtórz test po zastąpieniu wyłącznie kontenera. Następnie przywróć bazę danych, załączniki, elementy Send, klucze i konfigurację w /data do pustej infrastruktury i potwierdź, że elementy sejfu, załączniki, elementy Send i członkostwo w organizacji poprawnie synchronizują się z czystym klientem po przywróceniu. Podczas obu pomyślnych uruchomień mierz rozmiar załączników, rywalizację o zapis w SQLite lub limity puli połączeń z bazą danych oraz opóźnienia SMTP podczas wysyłania zaproszeń; nieoczekiwane różnice często ujawniają brakujący cache, indeks, workera lub mount danych.

Dodaj ćwiczenie awaryjne: tymczasowo zablokuj ścieżkę testową używaną przez działający SMTP, jeśli potrzebne są zaproszenia i wiadomości dotyczące emergency access. Vaultwarden powinien wygenerować użyteczny błąd, zachować istniejący stan i odzyskać sprawność po przywróceniu prawidłowych warunków. Zapisz znaczniki czasu i odpowiednie linie logów, usuwając z nich sekrety. Te dowody staną się punktem odniesienia przy kolejnej zmianie obrazu lub konfiguracji.

Obserwuj workload, a nie tylko kontener

Działający kontener jest konieczny, ale niewystarczający. Wskaźnikiem na poziomie usługi jest pomyślne zakończenie operacji „zalogowanie się z rozszerzenia przeglądarki, utworzenie elementu, synchronizacja drugiego klienta, przesłanie załącznika i pobranie elementu Send po restarcie”, natomiast prawdopodobne sygnały przeciążenia to rozmiar załączników, rywalizacja o zapis w SQLite lub limity puli połączeń z bazą danych oraz opóźnienia SMTP podczas wysyłania zaproszeń.

Kontrola zmian ma znaczenie, ponieważ migracje bazy danych Vaultwarden i zgodność z klientami Bitwarden trzeba sprawdzać razem; rotacja ADMIN_TOKEN to zmiana dostępu administratora, a nie migracja danych sejfu. Zachowaj stary obraz, przetestuj migracje na skopiowanym stanie i udokumentuj, czy rollback jest obsługiwany po zmianie schematu. Jeśli DOMAIN wskazuje HTTP, podczas gdy przeglądarka wymaga bezpiecznego originu dla funkcji sejfu, zdiagnozuj pierwszą granicę, która różni się od działającego środowiska.

Usuń tymczasowy dostęp konfiguracyjny

Bezpieczne wdrożenie Vaultwarden zaczyna się od odebrania uprawnień. Unikaj używania słabego tokenu administratora lub pozostawiania otwartej rejestracji; zamiast tego wyłącz otwartą rejestrację po zakończeniu dodawania użytkowników, zabezpiecz panel administratora silnym tokenem i wymagaj HTTPS dla każdego klienta sejfu.

Natychmiast zastąp przykładowy ADMIN_TOKEN, przechowuj go poza obrazem i rotuj jak poświadczenie administratora, jeśli zostanie ujawniony. Ogranicz trasy administracyjne, używaj prywatnego DNS dla zależności i przejrzyj każdy bind mount. Gdy logi są wysyłane centralnie, przefiltruj sekrety i prywatne treści, zanim opuszczą serwer.

Użyj Dockup dla warstwy platformy

Dockup usuwa konieczność ręcznej obsługi reverse proxy i lifecycle wokół Vaultwarden. Podczas zastępowania usługa otrzymuje stabilną trasę HTTPS do portu 80, wstrzykniętą konfigurację i persistent storage. Podłączony serwer klienta działa zgodnie z tym samym modelem co compute hostowany przez Dockup.

Po uruchomieniu spełnij kontrakt aplikacji: ustaw DOMAIN na dokładny zewnętrzny origin HTTPS, zezwól na działający SMTP i zweryfikuj go, jeśli potrzebne są zaproszenia i wiadomości dotyczące emergency access, a następnie wykonaj ten test: zaloguj się z rozszerzenia przeglądarki, utwórz element, zsynchronizuj drugiego klienta, prześlij załącznik i pobierz element Send po restarcie. Dzięki temu obsługa jednym kliknięciem pozostaje użyteczna, bez pomijania szczegółów, które decydują o możliwości odzyskania Vaultwarden i jego bezpieczeństwie.

Najczęściej zadawane pytania

Czego Vaultwarden potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener Vaultwarden na porcie 80 przez jeden origin HTTPS. Zewnętrznym wymaganiem dostarczania jest działający SMTP, jeśli potrzebne są zaproszenia i wiadomości dotyczące emergency access. Nie uznawaj Vaultwarden za gotowy, dopóki nie możesz zalogować się z rozszerzenia przeglądarki, utworzyć elementu, zsynchronizować drugiego klienta, przesłać załącznika i pobrać elementu Send po restarcie.

Które dane Vaultwarden powinny znaleźć się w kopii zapasowej?

Utrwal /data i uwzględnij w tym samym manifeście odzyskiwania bazę danych, załączniki, elementy Send, klucze i konfigurację w /data. Czyste przywrócenie Vaultwarden kończy się powodzeniem tylko wtedy, gdy elementy sejfu, załączniki, elementy Send i członkostwo w organizacji poprawnie synchronizują się z czystym klientem po przywróceniu.

Czy Vaultwarden wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Vaultwarden, a port 80 pozostaw na trasie wewnętrznej. Poprawnie zastosuj ustawienie Vaultwarden: ustaw DOMAIN na dokładny zewnętrzny origin HTTPS. W przypadku Vaultwarden HTTPS chroni poświadczenia lub treści użytkowników podczas przesyłania i zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Vaultwarden?

Przywróć bieżący stan Vaultwarden w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na to, że migracje bazy danych Vaultwarden i zgodność z klientami Bitwarden trzeba sprawdzać razem; rotacja ADMIN_TOKEN to zmiana dostępu administratora, a nie migracja danych sejfu. Zachowaj poprzedni obraz Vaultwarden, dopóki granice migracji danych i rollbacku nie będą zrozumiałe.