Как разместить Vaultwarden на собственном сервере в 2026 году: домены, SMTP и безопасные резервные копии

Есть два варианта «запустить Vaultwarden»: контейнер существует или сервис действительно выполняет свою задачу. Важен только второй. В этом случае проверка заключается в том, чтобы войти через browser extension, создать элемент, синхронизировать второй клиент, загрузить вложение и получить Send после перезапуска.

Vaultwarden предназначен именно для этого: это компактный password server, совместимый с Bitwarden. При развёртывании нужно сохранить все компоненты, обеспечивающие такую работу: порт, volume и сертификат — это входные параметры, а не результат.

Volumes — только первый уровень восстановления

Полный набор для восстановления включает database, attachments, sends, keys и configuration в /data. Подключите /data до bootstrap, запишите безобидные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняет данные. Volume защищает данные от замены контейнера, но не от потери host, случайного удаления или повреждения на уровне приложения.

Создавайте резервные копии с учётом источника данных: при необходимости используйте logical dumps для работающих databases и копируйте файлы только из согласованного состояния. Храните одну зашифрованную копию отдельно от Vaultwarden host. Критерий успешного восстановления должен быть конкретным: vault items, attachments, Sends и organization membership корректно синхронизируются с чистым клиентом после восстановления. В руководстве по резервным копиям, восстановление которых было проверено объясняется, почему одного успешного завершения job недостаточно.

Запускайте Vaultwarden, не скрывая ключевые компоненты

Запускайте Vaultwarden так, чтобы route оставался приватным до завершения 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

Если процесс зацикливается, сравните ожидаемого пользователя image с владельцем каждого подключённого path. Если контейнер продолжает работать, проверьте port 80 локально и сразу перейдите к workflow: войдите через browser extension, создайте элемент, синхронизируйте второй клиент, загрузите attachment и получите Send после restart. Фиксируйте версию image только после успешной end-to-end проверки и сохраните точную configuration рядом с сервисом.

Определите runtime boundary Vaultwarden

Определите для Vaultwarden три boundary: ingress к port 80, durable state и supporting requirements. Контейнер можно заменить, но для двух остальных компонентов нужны явно назначенные владельцы. Внешнее требование Vaultwarden — working SMTP, если нужны invitations и письма для emergency access. Проверьте outbound DNS, TLS и поведение provider, не публикуя ещё один inbound service.

Диаграмма считается полной, когда чистый клиент может войти через browser extension, создать элемент, синхронизировать второй клиент, загрузить attachment и получить Send после restart. Соберите данные о timing и resources для attachment volume, SQLite write contention или database pool limits, а также SMTP latency во время invitations. Если transaction завершается ошибкой, первая boundary, которая ведёт себя не так, как описано в документации, указывает, нужно ли исследовать routing, local capacity или supporting service.

Разделяйте внутренние и внешние URL

Не используйте для Vaultwarden временные и постоянные public origins. Вместо этого задайте DOMAIN, равный точному внешнему HTTPS origin, направьте выбранное DNS-имя на platform route и проксируйте запросы только к port 80.

Выполните эту проверку извне host: войдите через browser extension, создайте элемент, синхронизируйте второй клиент, загрузите attachment и получите Send после restart. Если ingress не работает, в руководстве по устранению 502 разобраны ошибки с port и listener. Если Vaultwarden получает запрос, но DOMAIN содержит HTTP, тогда как browser требует secure origin для функций vault, это указывает, что проблема находится за пределами proxy.

Production acceptance run для Vaultwarden

Production gate для Vaultwarden должен быть выполним человеком, который не занимался развёртыванием. Передайте ему зафиксированную версию, несекретную тестовую учётную запись и это задание: войти через browser extension, создать элемент, синхронизировать второй клиент, загрузить attachment и получить Send после restart. Если инструкции требуют undocumented shell access, сервис ещё не готов к эксплуатации.

Повторите gate, заменив только контейнер. Затем восстановите database, attachments, sends, keys и configuration в /data на пустой infrastructure и убедитесь, что vault items, attachments, Sends и organization membership корректно синхронизируются с чистым клиентом после восстановления. Во время обоих успешных запусков измеряйте attachment volume, SQLite write contention или database pool limits, а также SMTP latency во время invitations; неожиданные различия часто выявляют отсутствующий cache, index, worker или data mount.

Добавьте failure drill: временно запретите test path, используемый working SMTP, если нужны invitations и письма для emergency access. Vaultwarden должен выдать понятную ошибку, сохранить существующее состояние и восстановить работу после возвращения корректного условия. Сохраните timestamps и соответствующие строки логов, предварительно удалив secrets. Эти данные станут эталоном для следующего изменения image или configuration.

Следите за workload, а не только за контейнером

Зелёный контейнер необходим, но недостаточен. Service-level indicator — успешное выполнение сценария «войти через browser extension, создать элемент, синхронизировать второй клиент, загрузить attachment и получить Send после restart», а наиболее вероятные pressure signals — attachment volume, SQLite write contention или database pool limits, а также SMTP latency во время invitations.

Change control важен, поскольку migrations базы данных Vaultwarden и совместимость клиентов Bitwarden нужно проверять вместе; ротация ADMIN_TOKEN — это изменение administrator access, а не migration vault data. Сохраняйте старый image, тестируйте migrations на копии state и документируйте, поддерживается ли rollback после изменения schema. Если DOMAIN содержит HTTP, а browser требует secure origin для функций vault, определите первую boundary, которая отличается от рабочего окружения.

Закройте временный доступ для настройки

Безопасное развёртывание Vaultwarden начинается с удаления избыточных прав. Не используйте слабый admin token и не оставляйте sign-ups открытыми: после завершения enrollment отключите open sign-up, защитите admin page сильным token и требуйте HTTPS для каждого vault client.

Немедленно замените демонстрационный ADMIN_TOKEN, храните его вне image и ротируйте как administrator credential, если он оказался раскрыт. Ограничьте administrative routes, используйте private DNS для dependencies и проверьте каждый bind mount. Если логи отправляются в централизованную систему, отфильтруйте secrets и private content до того, как они покинут server.

Используйте Dockup для platform layer

Dockup устраняет ручную работу с reverse proxy и lifecycle вокруг Vaultwarden. При замене сервис получает стабильный HTTPS route к port 80, injected configuration и persistent storage. Подключённый customer server работает по той же модели, что и compute, размещённый в Dockup.

После запуска выполните application contract: задайте DOMAIN, равный точному внешнему HTTPS origin, разрешите и проверьте working SMTP, если нужны invitations и письма для emergency access, а затем выполните проверку: войдите через browser extension, создайте элемент, синхронизируйте второй клиент, загрузите attachment и получите Send после restart. Это сохраняет удобство one-click experience, не скрывая детали, благодаря которым Vaultwarden можно восстановить и безопасно эксплуатировать.

Часто задаваемые вопросы

Что нужно Vaultwarden для production deployment?

Направьте контейнер Vaultwarden через port 80 к одному HTTPS origin. Внешнее delivery requirement — working SMTP, если нужны invitations и письма для emergency access. Не считайте Vaultwarden готовым, пока не сможете войти через browser extension, создать элемент, синхронизировать второй клиент, загрузить attachment и получить Send после restart.

Какие данные Vaultwarden нужно включать в резервную копию?

Сохраняйте /data и включайте database, attachments, sends, keys и configuration в /data в единый recovery manifest. Чистое восстановление Vaultwarden считается успешным только тогда, когда vault items, attachments, Sends и organization membership корректно синхронизируются с чистым клиентом после восстановления.

Нужен ли Vaultwarden HTTPS за reverse proxy?

Используйте HTTPS для public origin Vaultwarden, а port 80 оставьте во внутреннем route. Корректно задайте настройку Vaultwarden: DOMAIN должен точно соответствовать внешнему HTTPS origin. Для Vaultwarden HTTPS защищает credentials и пользовательский content при передаче и обеспечивает согласованное поведение клиента, зависящее от origin.

Как тестировать обновление Vaultwarden?

Восстановите текущее состояние Vaultwarden в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание: migrations базы данных Vaultwarden и совместимость клиентов Bitwarden нужно проверять вместе; ротация ADMIN_TOKEN — это изменение administrator access, а не migration vault data. Сохраняйте предыдущий image Vaultwarden, пока не будут понятны границы data migration и rollback.