Як розгорнути Vaultwarden на власному сервері у 2026 році: домени, SMTP і безпечні резервні копії

Є дві версії «запуску Vaultwarden»: контейнер існує або сервіс виконує свою реальну функцію. Важлива лише друга. Тут перевіркою є вхід через browser extension, створення елемента, синхронізація другого клієнта, завантаження вкладення та отримання Send після перезапуску.

Vaultwarden виконує саме цю функцію: це компактний password server, сумісний із Bitwarden. Розгортання має зберігати всі складові, що забезпечують таку поведінку; порт, volume і certificate — це вхідні параметри, а не результат.

Volumes — лише перший рівень відновлення

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

Створюйте резервні копії з урахуванням джерела даних: за потреби використовуйте logical dumps для активних databases, а файли копіюйте лише з узгодженого стану. Зберігайте одну зашифровану копію окремо від хоста Vaultwarden. Критерій приймання відновлення має бути конкретним: vault items, attachments, Sends і organization membership мають коректно синхронізуватися з чистим клієнтом після відновлення. У посібнику з резервних копій, відновлення яких уже перевірено пояснюється, чому одного успішного виконання job недостатньо.

Запускайте Vaultwarden, не приховуючи важливі компоненти

Запускайте Vaultwarden так, щоб до завершення початкового налаштування route залишався приватним.

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

Якщо процес зациклюється, порівняйте очікуваного user образу з owner кожного підключеного path. Якщо контейнер працює стабільно, перевірте port 80 локально й одразу перейдіть до workflow: виконайте вхід через browser extension, створіть елемент, синхронізуйте другого клієнта, завантажте вкладення та отримайте Send після перезапуску. Фіксуйте версію image лише після успішної наскрізної перевірки й збережіть точну configuration поруч із сервісом.

Визначте межі середовища виконання Vaultwarden

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

Схема готова, коли чистий клієнт може виконати вхід через browser extension, створити елемент, синхронізувати другого клієнта, завантажити вкладення та отримати Send після перезапуску. Збирайте дані про час і використання ресурсів для attachment volume, SQLite write contention або database pool limits, а також SMTP latency під час invitations. Якщо transaction завершується помилкою, перша межа, яка поводиться не так, як задокументовано, вказує, чи потрібно досліджувати routing, локальну capacity або supporting service.

Розрізняйте внутрішні та зовнішні URL

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

Виконайте цю дію з-поза хоста: виконайте вхід через browser extension, створіть елемент, синхронізуйте другого клієнта, завантажте вкладення та отримайте Send після перезапуску. Якщо ingress не працює, у посібнику з усунення помилки 502 описано проблеми з port і listener. Якщо Vaultwarden отримує запит, але DOMAIN має значення HTTP, тоді як browser вимагає secure origin для функцій vault, докази вже вказують за межі proxy.

Перевірка Vaultwarden перед використанням у production

Production gate для Vaultwarden має бути виконуваним людиною, яка не налаштовувала це розгортання. Передайте їй pinned version, тестовий account без чутливих даних і таке завдання: виконати вхід через browser extension, створити елемент, синхронізувати другого клієнта, завантажити вкладення та отримати Send після перезапуску. Якщо інструкції вимагають undocumented shell access, сервіс ще не готовий до експлуатації.

Повторіть перевірку, замінивши лише контейнер. Потім відновіть 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 має видати зрозумілу помилку, зберегти наявний state і відновити роботу після повернення коректної умови. Збережіть часові мітки та відповідні log lines, попередньо замінивши secrets на безпечні позначки. Ці докази стануть еталоном для наступної зміни image або configuration.

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

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

Change control має значення, оскільки database migrations Vaultwarden і сумісність Bitwarden client потрібно перевіряти разом; ротація ADMIN_TOKEN — це зміна доступу адміністратора, а не міграція vault data. Збережіть попередній image, тестуйте migrations на копії state і задокументуйте, чи підтримується rollback після зміни schema. Якщо DOMAIN має значення HTTP, тоді як browser вимагає secure origin для функцій vault, визначте першу межу, яка відрізняється від робочого середовища.

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

Безпечне розгортання Vaultwarden починається з усунення зайвих повноважень. Не використовуйте слабкий admin token і не залишайте sign-ups відкритими; натомість вимкніть open sign-up після завершення enrollment, захистіть admin page надійним 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. Під час заміни сервіс отримує стабільний HTTPS route до port 80, injected configuration і persistent storage. Підключений customer server працює за тією самою моделлю, що й compute у Dockup.

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

Поширені запитання

Що потрібно Vaultwarden для розгортання в production?

Спрямуйте контейнер Vaultwarden на port 80 через один HTTPS origin. Зовнішня вимога для delivery — working SMTP, якщо потрібні invitations і листи для emergency access. Не вважайте Vaultwarden готовим, доки не зможете увійти через browser extension, створити елемент, синхронізувати другого клієнта, завантажити вкладення та отримати Send після перезапуску.

Які дані 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 залиште для internal route. Коректно застосуйте налаштування Vaultwarden: задайте DOMAIN як точний зовнішній HTTPS origin. Для Vaultwarden HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену поведінку client, чутливу до origin.

Як тестувати оновлення Vaultwarden?

Відновіть поточний state Vaultwarden в ізольованому deployment, застосуйте candidate version і повторіть acceptance transaction. Зверніть особливу увагу на те, що database migrations Vaultwarden і сумісність Bitwarden client потрібно перевіряти разом; ротація ADMIN_TOKEN — це зміна доступу адміністратора, а не міграція vault data. Зберігайте попередній image Vaultwarden, доки не визначите межі data migration і rollback.