Vaultwarden — незалежна реалізація сервера Bitwarden на Rust, сумісна з офіційними клієнтами і браузерними розширеннями, але помітно легша за вимогами до ресурсів. Для команди, яка не хоче тримати паролі в хмарному сервісі з чужою інфраструктурою, Vaultwarden на власному VDS — робочий варіант, якщо адміністратор готовий відповідати за резервні копії, оновлення і доступ до сервера сам.
Що таке Vaultwarden і коли він доречний
Vaultwarden зберігає зашифроване сховище паролів і синхронізує його з офіційними застосунками Bitwarden для десктопа, мобільних платформ і браузерів — з погляду клієнта різниця з хмарним Bitwarden непомітна, крім адреси сервера, яка вказується під час першого входу. На відміну від офіційного серверного ПЗ Bitwarden, написаного на .NET, Vaultwarden потребує помітно менше пам'яті і процесорного часу, тому його можна розмістити на невеликому VDS разом з іншими сервісами.
Self-hosted варіант доречний, коли команда готова взяти на себе оновлення, моніторинг і резервне копіювання сама: на відміну від хмарного сервісу, тут ніхто не відновить доступ, якщо втрачено і мастер-пароль, і резервну копію бази одночасно. Якщо такої готовності немає, безпечніше залишитися на одному з менеджерів паролів, розглянутих у статті «Безпечні паролі і менеджери паролів».
Запуск у Docker
Vaultwarden офіційно постачається як образ Docker, і запуск через docker-compose — найбільш передбачуваний спосіб розгорнути його на VDS: оновлення зводиться до зміни тегу образу і перезапуску контейнера, а не до ручної установки залежностей. Базові кроки підготовки Docker на сервері описані у статті «Docker на VPS: встановлення і запуск контейнерів».
Дані — зашифрована база SQLite (або зовнішній PostgreSQL для навантажених випадків) і папка з прикладеними файлами — мають лежати в volume, змонтованому з хоста, а не всередині шару контейнера: під час оновлення образу шар контейнера перестворюється, і все, що залишилося всередині нього, а не у volume, буде втрачено.
TLS і зворотний проксі
Клієнти Bitwarden відмовляються працювати з сервером без дійсного HTTPS, тому Vaultwarden майже завжди розгортають за зворотним проксі, який бере на себе TLS, а сам сервіс слухає лише внутрішній порт. Nginx із сертифікатом від Let's Encrypt — стандартна зв'язка; порядок випуску і продовження сертифіката описаний у статті «Встановлення SSL на Nginx за допомогою Certbot».
Окреме правило — ендпоінт WebSocket для живих сповіщень між пристроями: його потрібно явно проксувати із заголовками Upgrade і Connection, інакше синхронізація між клієнтами працюватиме лише за таймером, а не миттєво.
Токен адміністратора і обмеження реєстрації
Панель адміністратора Vaultwarden за умовчанням доступна за шляхом /admin і захищена лише токеном, заданим змінною середовища ADMIN_TOKEN: якщо токен не задано або він слабкий, панель відкрита практично будь-кому, хто дізнається шлях. Токен варто генерувати довгим випадковим рядком і зберігати лише у змінних середовища, а не у файлі, який може опинитися в репозиторії.
За умовчанням сервер дозволяє реєстрацію нових користувачів усім, хто знає адресу. Для команди з відомим складом реєстрацію потрібно закрити змінною SIGNUPS_ALLOWED=false одразу після створення потрібних облікових записів, інакше база залишиться відкритою для стороньої реєстрації.
Резервні копії
Втрата бази Vaultwarden без резервної копії означає повну втрату всіх збережених паролів одразу, а не одного сервісу — це відрізняє менеджер паролів від більшості інших сервісів на VDS за тяжкістю наслідків збою. Резервну копію файлу бази і папки з прикладеннями потрібно знімати регулярно і зберігати окремо від самого сервера, а не лише локально поруч з даними.
Сама зашифрована база марна без мастер-пароля користувача, тому резервну копію можна зберігати менш суворо, ніж, наприклад, незашифрований дамп платіжних даних, але доступ до неї все одно варто обмежити: за резервною копією можна підбирати мастер-пароль офлайн, без обмежень на кількість спроб, які є у живого сервера.
- HTTPS увімкнено, і клієнти підключаються лише за захищеною адресою
- ADMIN_TOKEN заданий довгим випадковим рядком, а не залишений порожнім
- SIGNUPS_ALLOWED вимкнено після створення потрібних облікових записів
- Дані винесені у volume, а не зберігаються всередині шару контейнера
- Резервна копія бази і файлів налаштована і перевірена відновленням
| Параметр | Значення за умовчанням | Рекомендація |
|---|---|---|
| ADMIN_TOKEN | не задано | довгий випадковий рядок у змінних середовища |
| SIGNUPS_ALLOWED | true | false після створення облікових записів |
| Зберігання даних | SQLite у контейнері | volume на хості, винесений за межі шару образу |
| Оперативна пам'ять | — | зазвичай достатньо 512 MB-1 GB для невеликої команди |
services:
vaultwarden:
image: vaultwarden/server:latest
restart: unless-stopped
environment:
- ADMIN_TOKEN=change-me-to-a-long-random-string
- SIGNUPS_ALLOWED=false
volumes:
- ./vw-data:/data
ports:
- "127.0.0.1:8080:80"Часті питання
Чи потрібно відкривати Vaultwarden без зворотного проксі і TLS хоча б для тесту?
Клієнти Bitwarden за умовчанням відмовляються підключатися до сервера без HTTPS, тому навіть для тесту простіше одразу налаштувати зворотний проксі із сертифікатом, ніж тимчасово використовувати HTTP і потім розбиратися, чому клієнт не синхронізується. Сертифікат можна випустити за кілька хвилин, і відкладати це налаштування на потім немає сенсу.
Скільки ресурсів VDS потрібно для Vaultwarden?
Для невеликої команди, як правило, достатньо 1 vCPU і 512 MB-1 GB оперативної пам'яті — Vaultwarden помітно легший за офіційний сервер Bitwarden на .NET. Точна цифра залежить від кількості користувачів, розміру прикладених файлів і того, які ще сервіси працюють на тому самому VDS.
Що робити, якщо забуто ADMIN_TOKEN?
Доступ до панелі адміністратора без правильного токена відновити неможливо — потрібно задати нове значення змінної ADMIN_TOKEN у конфігурації і перезапустити контейнер; це не вплине на вже збережені паролі користувачів. Мастер-пароль користувача — окремий секрет, і втрата ADMIN_TOKEN на нього не впливає.