Jak provozovat Vaultwarden na vlastním serveru v roce 2026: domény, SMTP a bezpečné zálohy

„Spouštění Vaultwardenu“ může znamenat dvě různé věci: buď existuje container, nebo služba skutečně plní svůj účel. Důležitá je pouze druhá možnost. Důkazem je přihlášení z rozšíření prohlížeče, vytvoření položky, synchronizace druhého klienta, nahrání přílohy a načtení Sendu po restartu.

Vaultwarden slouží jako kompaktní password server kompatibilní s Bitwardenem. Nasazení musí zachovat všechny části, které toto chování zajišťují; port, volume a certifikát jsou vstupy, nikoli výsledek.

Volumes jsou pouze první vrstvou obnovy

Trvalá sada pro obnovu zahrnuje databázi, přílohy, Sends, klíče a konfiguraci v /data. Připojte /data ještě před bootstrapem, zapište neškodná testovací data a nahraďte container, abyste ověřili, že je tato cesta skutečně perzistentní. Volume chrání data před nahrazením containeru, nikoli před ztrátou hostitele, náhodným smazáním nebo poškozením na úrovni aplikace.

Vytvářejte zálohy s ohledem na zdroj dat: u běžících databází podle potřeby používejte logické dumpy a soubory kopírujte pouze z konzistentního stavu. Jednu šifrovanou kopii uchovávejte mimo hostitele Vaultwardenu. Kritérium úspěšné obnovy musí být konkrétní — položky trezoru, přílohy, Sends a členství v organizacích se po obnově správně synchronizují s čistým klientem. Průvodce zálohami ověřenými obnovou vysvětluje, proč samotný úspěšný běh úlohy nestačí.

Spusťte Vaultwarden, aniž byste skryli jednotlivé části

Spusťte Vaultwarden tak, aby route zůstala během bootstrapu privátní.

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

Pokud proces opakovaně končí, porovnejte očekávaného uživatele image s vlastníkem každé připojené cesty. Pokud zůstane běžet, otestujte lokálně port 80 a poté rovnou projděte celý workflow: přihlaste se z rozšíření prohlížeče, vytvořte položku, synchronizujte druhého klienta, nahrajte přílohu a po restartu načtěte Send. Image připněte na konkrétní verzi až po úspěšném end-to-end ověření a přesnou konfiguraci zaznamenejte vedle služby.

Vymezte runtime hranice Vaultwardenu

Kolem Vaultwardenu vymezte tři hranice: ingress na port 80, trvalý stav a podpůrné požadavky. Container lze nahradit, ale zbývající dvě oblasti musí mít jasně určené vlastníky. Externím požadavkem Vaultwardenu je funkční SMTP, pokud jsou potřeba pozvánky a e-maily pro nouzový přístup. Otestujte odchozí DNS, TLS a chování poskytovatele, aniž byste publikovali další inbound službu.

Diagram je kompletní ve chvíli, kdy se čistý klient dokáže přihlásit z rozšíření prohlížeče, vytvořit položku, synchronizovat druhého klienta, nahrát přílohu a po restartu načíst Send. Zaznamenávejte časové a resource metriky pro objem příloh, kolize zápisů do SQLite nebo limity databázového poolu a latenci SMTP při odesílání pozvánek. Pokud transakce selže, první hranice, která se nechová podle dokumentace, ukazuje, zda je třeba zkoumat routing, lokální kapacitu nebo podpůrnou službu.

Rozlišujte interní a externí URL

Vyhněte se dočasným i trvalým veřejným originům pro Vaultwarden. Místo toho nastavte DOMAIN na přesný externí HTTPS origin, nasměrujte zvolený DNS název na route platformy a proxy konfigurujte pouze na port 80.

Tuto akci proveďte mimo hostitele: přihlaste se z rozšíření prohlížeče, vytvořte položku, synchronizujte druhého klienta, nahrajte přílohu a po restartu načtěte Send. Pokud ingress selhává, průvodce řešením chyby 502 popisuje chyby v portech a listenerech. Pokud Vaultwarden požadavek přijme, ale DOMAIN používá HTTP, zatímco prohlížeč vyžaduje pro funkce trezoru secure origin, důkazy nyní ukazují mimo proxy.

Produkční akceptační test Vaultwardenu

Produkční gate pro Vaultwarden musí být proveditelný člověkem, který nasazení nevytvořil. Předejte mu připnutou verzi, testovací účet bez citlivých údajů a tento úkol: přihlásit se z rozšíření prohlížeče, vytvořit položku, synchronizovat druhého klienta, nahrát přílohu a po restartu načíst Send. Pokud pokyny vyžadují nedokumentovaný přístup přes shell, služba ještě není provozně připravená.

Gate zopakujte po nahrazení pouze containeru. Poté obnovte databázi, přílohy, Sends, klíče a konfiguraci v /data do prázdné infrastruktury a ověřte, že se položky trezoru, přílohy, Sends a členství v organizacích po obnově správně synchronizují s čistým klientem. Během obou úspěšných běhů měřte objem příloh, kolize zápisů do SQLite nebo limity databázového poolu a latenci SMTP při odesílání pozvánek; neočekávané rozdíly často odhalí chybějící cache, index, worker nebo mount dat.

Přidejte také failure drill: dočasně zablokujte testovací cestu používanou funkčním SMTP, pokud jsou potřeba pozvánky a e-maily pro nouzový přístup. Vaultwarden by měl vypsat užitečnou chybu, zachovat existující stav a po návratu platné podmínky se zotavit. Uložte časová razítka a relevantní řádky logu, přičemž tajné údaje začerňte. Tyto důkazy se stanou referencí pro další změnu image nebo konfigurace.

Sledujte workload, ne pouze container

Zelený container je nutnou, nikoli však dostačující podmínkou. Service-level indicator představuje úspěšné dokončení operace „přihlásit se z rozšíření prohlížeče, vytvořit položku, synchronizovat druhého klienta, nahrát přílohu a po restartu načíst Send“, zatímco pravděpodobnými signály přetížení jsou objem příloh, kolize zápisů do SQLite nebo limity databázového poolu a latence SMTP při odesílání pozvánek.

Change control je důležitý, protože migrace databáze Vaultwardenu a kompatibilitu klienta Bitwarden je nutné kontrolovat společně; rotace ADMIN_TOKEN je změna administrátorského přístupu, nikoli migrace dat trezoru. Zachovejte starou image, migrace testujte na zkopírovaném stavu a zdokumentujte, zda je po změně schématu podporován rollback. Pokud DOMAIN používá HTTP, zatímco prohlížeč vyžaduje pro funkce trezoru secure origin, hledejte první hranici, která se liší od funkčního prostředí.

Uzavřete dočasný přístup pro nastavení

Bezpečné nasazení Vaultwardenu začíná odebráním oprávnění. Nepoužívejte slabý admin token ani nenechávejte otevřené registrace; po dokončení enrollmentu vypněte otevřené registrace, chraňte admin stránku silným tokenem a vyžadujte HTTPS pro každého klienta trezoru.

Ukázkový ADMIN_TOKEN ihned nahraďte, uložte jej mimo image a při jeho úniku jej rotujte stejně jako administrátorské přihlašovací údaje. Omezte administrativní routes, pro závislosti používejte privátní DNS a zkontrolujte každý bind mount. Pokud logy odesíláte do centrálního systému, odfiltrujte tajné údaje a soukromý obsah ještě před jejich opuštěním serveru.

Použijte Dockup pro platformní vrstvu

Dockup odstraňuje ruční práci s reverse proxy a životním cyklem kolem Vaultwardenu. Služba při nahrazování dostane stabilní HTTPS route na port 80, injektovanou konfiguraci a persistent storage. Připojený zákaznický server funguje podle stejného modelu jako compute hostovaný na Dockupu.

Po spuštění splňte aplikační kontrakt: nastavte DOMAIN na přesný externí HTTPS origin, povolte a ověřte funkční SMTP, pokud jsou potřeba pozvánky a e-maily pro nouzový přístup, a proveďte tento test: přihlaste se z rozšíření prohlížeče, vytvořte položku, synchronizujte druhého klienta, nahrajte přílohu a po restartu načtěte Send. Díky tomu zůstane one-click experience užitečný, aniž by se zjednodušily detaily, které zajišťují obnovitelnost a bezpečnost Vaultwardenu.

Často kladené otázky

Co Vaultwarden potřebuje pro produkční nasazení?

Veďte container Vaultwardenu na portu 80 přes jeden HTTPS origin. Externím požadavkem na doručování je funkční SMTP, pokud jsou potřeba pozvánky a e-maily pro nouzový přístup. Vaultwarden neoznačujte za připravený, dokud se nedokážete přihlásit z rozšíření prohlížeče, vytvořit položku, synchronizovat druhého klienta, nahrát přílohu a po restartu načíst Send.

Která data Vaultwardenu patří do zálohy?

Zachovejte /data a do stejného recovery manifestu zahrňte databázi, přílohy, Sends, klíče a konfiguraci v /data. Čistá obnova Vaultwardenu je úspěšná teprve tehdy, když se položky trezoru, přílohy, Sends a členství v organizacích po obnově správně synchronizují s čistým klientem.

Vyžaduje Vaultwarden HTTPS za reverse proxy?

Pro veřejný origin Vaultwardenu používejte HTTPS a port 80 ponechte na interní route. Nastavení Vaultwardenu aplikujte správně: nastavte DOMAIN na přesný externí HTTPS origin. U Vaultwardenu HTTPS chrání přihlašovací údaje nebo uživatelský obsah při přenosu a udržuje konzistentní chování klienta závislé na originu.

Jak testovat upgrade Vaultwardenu?

Obnovte aktuální stav Vaultwardenu do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte jeho akceptační transakci. Věnujte tomu zvláštní pozornost, protože migrace databáze Vaultwardenu a kompatibilitu klienta Bitwarden je nutné kontrolovat společně; rotace ADMIN_TOKEN je změna administrátorského přístupu, nikoli migrace dat trezoru. Předchozí image Vaultwardenu ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.