Как да хоствате Vaultwarden самостоятелно през 2026 г.: домейни, SMTP и сигурни резервни копия

Има две версии на „използването на Vaultwarden“: съществува контейнер или услугата изпълнява реалната си задача. Важна е само втората. Тук доказателството е да влезете през browser extension, да създадете елемент, да синхронизирате втори клиент, да качите прикачен файл и да извлечете Send след рестартиране.

Vaultwarden изпълнява следната роля: компактен password server, съвместим с Bitwarden. Deployment-ът трябва да запази компонентите, които осигуряват това поведение; порт, volume и сертификат са входни данни, а не резултат.

Volumes са само първият слой за възстановяване

Наборът от данни за надеждно възстановяване включва database, attachments, sends, keys и configuration в /data. Монтирайте /data преди bootstrap, запишете безобидни примерни данни и заменете контейнера, за да докажете, че този path действително е persistent. Volume защитава данните при замяна на контейнера, но не и при загуба на host-а, случайно изтриване или повреда на ниво application.

Създавайте backups, които разбират източника на данни: използвайте logical dumps за активни databases, когато е необходимо, и копирайте файлове само от консистентно състояние. Съхранявайте едно криптирано копие извън host-а на Vaultwarden. Критерият за приемане при restore е конкретен — vault items, attachments, Sends и membership-ът в organization трябва да се синхронизират коректно с clean client след restore. Ръководството за backup-и, тествани чрез restore обяснява защо само успешното изпълнение на job не е достатъчно.

Стартирайте Vaultwarden, без да прикривате компонентите

Стартирайте Vaultwarden по начин, който оставя route-а private, докато bootstrap-ът приключи.

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

Ако процесът влиза в loop, сравнете очаквания user на image-а със собственика на всеки mounted path. Ако остане активен, тествайте локално port 80 и след това преминете директно към workflow-а: влезте през browser extension, създайте елемент, синхронизирайте втори клиент, качете attachment и извлечете Send след рестартиране. Фиксирайте версията на image-а едва след като тази end-to-end проверка премине успешно и запишете точната configuration до service-а.

Определете runtime границите на Vaultwarden

Определете три граници около Vaultwarden: ingress към port 80, durable state и supporting requirements. Контейнерът може да бъде заменен, но за другите две са необходими изрично определени owners. Външното изискване за Vaultwarden е работещ SMTP, ако са нужни invitations и имейли за emergency access. Тествайте outbound DNS, TLS и поведението на provider-а, без да публикувате друга inbound услуга.

Диаграмата е завършена, когато clean client може да влезе през browser extension, да създаде елемент, да синхронизира втори клиент, да качи attachment и да извлече Send след рестартиране. Събирайте данни за timing и resource usage при attachment volume, SQLite write contention или database pool limits, както и за SMTP latency при invitations. Ако транзакцията се провали, първата граница, която не се държи според документацията, показва дали трябва да изследвате routing, local capacity или supporting service.

Разграничавайте правилно internal и external URL адресите

Избягвайте временни и постоянни public origins за Vaultwarden. Вместо това задайте DOMAIN към точния външен HTTPS origin, насочете избраното DNS име към platform route-а и правете proxy само към port 80.

Изпълнете това действие извън host-а: влезте през browser extension, създайте елемент, синхронизирайте втори клиент, качете attachment и извлечете Send след рестартиране. Ако ingress-ът не работи, ръководството за отстраняване на проблеми с 502 обхваща грешки в port-овете и listener-ите. Ако Vaultwarden получава request-а, но DOMAIN е HTTP, докато browser-ът изисква secure origin за vault функциите, доказателствата вече насочват отвъд proxy-то.

Production acceptance run за Vaultwarden

Production gate-ът за Vaultwarden трябва да може да бъде изпълнен от човек, който не е изградил deployment-а. Дайте му pinned version, non-sensitive test account и следната задача: да влезе през browser extension, да създаде елемент, да синхронизира втори клиент, да качи attachment и да извлече Send след рестартиране. Ако инструкциите изискват недокументиран shell достъп, service-ът все още не е готов за operational use.

Повторете gate-а, като замените само контейнера. След това възстановете database, attachments, sends, keys и configuration в /data в blank infrastructure и докажете, че vault items, attachments, Sends и membership-ът в organization се синхронизират коректно с clean client след restore. Измервайте attachment volume, SQLite write contention или database pool limits и SMTP latency при invitations и при двете успешни изпълнения; неочакваните разлики често разкриват липсващ cache, index, worker или data mount.

Добавете failure drill: временно блокирайте test path-а, използван от работещия SMTP, ако са нужни invitations и имейли за emergency access. Vaultwarden трябва да генерира полезна грешка, да запази съществуващото state и да се възстанови, когато валидното условие се върне. Запазете timestamps и съответните log lines, като премахнете secrets. Тези доказателства стават reference за следващата промяна на image или configuration.

Наблюдавайте workload-а, а не само контейнера

Зеленият контейнер е необходим, но не е достатъчен. Service-level indicator-ът е успешното изпълнение на „влизане през browser extension, създаване на елемент, синхронизиране на втори клиент, качване на attachment и извличане на Send след рестартиране“, а вероятните сигнали за натоварване са attachment volume, SQLite write contention или database pool limits и SMTP latency при invitations.

Change control-ът е важен, защото database migrations на Vaultwarden и съвместимостта с Bitwarden clients трябва да се проверяват заедно; ротацията на ADMIN_TOKEN е промяна в administrator access, а не migration на vault data. Запазете стария image, тествайте migrations върху копирано state и документирайте дали rollback се поддържа след промяна на schema. Ако DOMAIN е HTTP, докато browser-ът изисква secure origin за vault функциите, диагностицирайте първата граница, която се различава от работещата environment.

Затворете временния setup достъп

Сигурният deployment на Vaultwarden започва с премахване на излишните права. Избягвайте слаб admin token или оставени отворени sign-ups; вместо това изключете open sign-up след приключване на enrollment-а, защитете admin страницата със силен token и изисквайте HTTPS за всеки vault client.

Сменете примерния ADMIN_TOKEN незабавно, съхранявайте го извън image-а и го ротирайте като administrator credential, ако бъде разкрит. Ограничете administrative routes, използвайте private DNS за dependencies и прегледайте всеки bind mount. Когато logs се изпращат към централизирана система, филтрирайте secrets и private content, преди да напуснат server-а.

Използвайте Dockup за platform layer-а

Dockup премахва ръчната работа по reverse proxy и lifecycle около Vaultwarden. Service-ът получава стабилен HTTPS route към 80, injected configuration и persistent storage при replacements. Свързан customer server следва същия модел като compute, хостван в Dockup.

След launch изпълнете application contract-а: задайте DOMAIN към точния външен HTTPS origin, разрешете и проверете работещ SMTP, ако са нужни invitations и имейли за emergency access, и изпълнете следното доказателство: влезте през browser extension, създайте елемент, синхронизирайте втори клиент, качете attachment и извлечете Send след рестартиране. Така one-click изживяването остава полезно, без да се скриват детайлите, които правят Vaultwarden възстановим и сигурен.

Често задавани въпроси

Какво е необходимо на Vaultwarden за production deployment?

Насочете Vaultwarden container-а на port 80 през един HTTPS origin. Външното изискване за delivery е работещ SMTP, ако са нужни invitations и имейли за emergency access. Не обявявайте Vaultwarden за готов, докато не можете да влезете през browser extension, да създадете елемент, да синхронизирате втори клиент, да качите attachment и да извлечете Send след рестартиране.

Кои данни на Vaultwarden трябва да бъдат включени в backup?

Запазете /data и включете database, attachments, sends, keys и configuration в /data в един и същ recovery manifest. Clean restore на Vaultwarden е успешен само когато vault items, attachments, Sends и membership-ът в organization се синхронизират коректно с clean client след restore.

Необходим ли е HTTPS за Vaultwarden зад reverse proxy?

Използвайте HTTPS за public Vaultwarden origin и запазете port 80 във вътрешния route. Задайте настройката на Vaultwarden правилно: DOMAIN трябва да сочи към точния външен HTTPS origin. При Vaultwarden HTTPS защитава credentials или user content при пренос и поддържа последователно поведение на client-а, зависимо от origin.

Как трябва да се тества upgrade на Vaultwarden?

Възстановете текущото state на Vaultwarden в isolated deployment, приложете candidate version и повторете acceptance транзакцията. Обърнете специално внимание, защото database migrations на Vaultwarden и съвместимостта с Bitwarden clients трябва да се проверяват заедно; ротацията на ADMIN_TOKEN е промяна в administrator access, а не migration на vault data. Запазете предишния Vaultwarden image, докато не изясните границите на data migration и rollback.