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 на него не влияет.