Vaultwarden — установка и настройка (Docker, сервер, HTTPS)

Нужен свой менеджер паролей без подписки, но с нормальным веб-интерфейсом, мобильными приложениями и синхронизацией? Обычно на этом этапе люди находят Vaultwarden, быстро запускают контейнер и упираются в три проблемы: нет HTTPS, не работает почта и непонятно, какие переменные реально обязательны.

Ниже — пошаговая схема, как развернуть Vaultwarden на сервере, закрыть базовые риски и довести установку до состояния, когда им уже можно пользоваться каждый день, а не “потестировать и забыть”.

Установка Vaultwarden (Docker и базовые способы)

Vaultwarden — это self-hosted сервер, совместимый с экосистемой Bitwarden. Проще всего запускать его в Docker: меньше зависимостей, быстрее обновления и меньше шансов сломать систему ручной сборкой.

Установка через Docker (основной способ)

Это лучший вариант для большинства: VPS, домашний мини-сервер, VM в Proxmox, даже слабый x86-хост. Вам нужен установленный Docker и отдельная папка под данные.

• плюс: быстрый старт за 1–2 команды;
• плюс: все данные хранятся в одном volume;
• минус: без reverse proxy не стоит публиковать наружу напрямую;
• минус: новички часто сразу открывают порт 80 в интернет без HTTPS.

Минимальный запуск:

docker pull vaultwarden/server:latest

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -e DOMAIN="https://vault.example.com" \
  -v /opt/vaultwarden/data:/data \
  -p 127.0.0.1:8000:80 \
  vaultwarden/server:latest

Здесь сервис слушает только localhost на хосте, а наружу его уже должен отдавать Nginx или Caddy. Это безопаснее, чем сразу пробрасывать контейнер на внешний 80/443.

Запуск через docker-compose

Для постоянного сервера docker-compose удобнее обычного docker run. Проще хранить конфиг, редактировать переменные, добавлять SMTP и обновлять контейнер без хаоса в истории команд.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "change_this_to_a_long_random_token"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8000:80"

Почему compose лучше для продакшена:

• все настройки лежат в одном файле;
• легче делать бэкапы и перенос;
• проще обновлять образ и откатываться;
• удобно добавлять прокси, почтовый relay, fail2ban и мониторинг.

Команды управления:

docker compose up -d
docker compose logs -f
docker compose pull
docker compose up -d

Установка на Debian (без Docker)

Этот путь встречается реже. Он нужен тем, кто сознательно хочет максимум контроля: собственный systemd unit, ручное управление бинарником, особая схема логирования или нестандартная среда без Docker.

Но у варианта без Docker есть цена:

• понадобится больше ручной настройки;
• обновления сложнее;
• сборка и зависимости требуют больше внимания;
• ошибки диагностики обычно неприятнее, чем в контейнере.

На практике без Docker имеет смысл идти только тогда, когда вы понимаете, зачем именно уходите от контейнерной модели. Для дома, VPS и малого офиса это почти всегда лишнее усложнение.

Минимальные требования и подготовка сервера

Для небольшого инстанса Vaultwarden обычно хватает 1 vCPU и 512–1024 МБ RAM. По диску требования скромные, но закладывайте запас не только под базу, а ещё под вложения, иконки, экспорт и резервные копии.

Перед установкой проверьте:

• есть ли домен или поддомен под сервис;
• настроены ли A/AAAA-записи;
• установлены ли Docker и reverse proxy;
• не заняты ли порты 80 и 443 другими сервисами.

Если сервер стоит дома, а не в дата-центре, заранее продумайте схему доступа и сеть. В этом контексте может пригодиться материал про что работает без интернета в домашней сети: он хорошо ложится на сценарий локального self-hosted сервиса.

Краткий вывод: для 90% случаев оптимальная схема — VPS или VM + Docker + reverse proxy + отдельная папка /data под постоянное хранилище.

Развёртывание сервера Vaultwarden

На этом этапе важно понять не только “что ставить”, но и “где это должно жить”. От этого зависит доступность, резервное копирование и общий уровень риска.

Что такое Vaultwarden server и как он работает

Vaultwarden — лёгкая альтернатива полному Bitwarden server для self-hosted сценариев. Он даёт веб-интерфейс, API для клиентов и нормальную синхронизацию без тяжёлой инфраструктуры.

По умолчанию чаще всего используют SQLite. Это нормально для одного пользователя, семьи или маленькой команды. Но как только растёт число пользователей, начинается интенсивная запись, появляются интеграции и требования к отказоустойчивости — стоит думать о PostgreSQL.

Где размещать (VPS, Proxmox, локальный сервер)

Выбор площадки зависит не от моды, а от того, как именно вы будете пользоваться сервисом.

• VPS — лучший баланс простоты и доступности. Подходит, если нужен внешний доступ 24/7.
• Proxmox — удобен, если у вас уже есть домашняя self-hosted инфраструктура и вы хотите снапшоты, VM или LXC.
• Локальный сервер — хороший вариант для домашней сети, но придётся отдельно думать о внешнем доступе, резерве питания и DNS.

Практические сценарии выбора:

• Если нужен просто личный менеджер паролей без возни — берите VPS.
• Если уже живёте в Proxmox — делайте отдельную VM или LXC под Vaultwarden.
• Если храните всё дома и не хотите зависеть от интернета — локальный сервер тоже нормален, но тогда продумайте VPN или хотя бы ограничение доступа по IP.

Использование Alpine / лёгких систем

Лёгкие системы вроде Alpine хороши там, где важны минимальный размер и быстрый старт. Но выгода заметнее на уровне хоста или VM, чем внутри логики самой статьи “как поднять Vaultwarden”.

Если вы разворачиваете сервис в Docker, то главная экономия обычно не в выборе “самого лёгкого Linux”, а в аккуратной архитектуре: отдельный контейнер, минимум открытых портов, внешняя проксификация, нормальные бэкапы.

Риск этого подхода: экономия нескольких сотен мегабайт легко превращается в лишние часы на диагностику нестандартной среды. Для большинства пользователей Debian/Ubuntu-хост с Docker проще и надёжнее.

Краткий вывод: размещение должно быть не “самым лёгким”, а самым предсказуемым для обслуживания и восстановления.

Настройка HTTPS и прокси (Nginx)

Именно здесь самодельные установки чаще всего становятся небезопасными. Контейнер у людей уже работает, но трафик либо идёт без шифрования, либо прокси сломан так, что не работают уведомления и часть функций клиентов.

Зачем нужен HTTPS

Vaultwarden — это сервер паролей. Даже если мастер-пароль не передаётся в открытом виде, запускать такой сервис без HTTPS — плохая идея. Браузеры, мобильные клиенты и расширения ожидают нормальный защищённый доступ, а вы без TLS получаете лишние предупреждения, проблемы с доверием и повышенный риск на сети.

На практике HTTPS нужен не “для галочки”, а по трём причинам:

• защищённый канал до сервера;
• нормальная работа клиентов и браузеров;
• предсказуемая схема с доменом и корректными ссылками в письмах.

Настройка Nginx reverse proxy

Логика простая: Nginx принимает запросы на домене, завершает TLS и проксирует их на локальный контейнер, например на 127.0.0.1:8000. Это стандартная и самая понятная схема для продакшена.

server {
    listen 80;
    server_name vault.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name vault.example.com;

    ssl_certificate /etc/letsencrypt/live/vault.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;

    client_max_body_size 128M;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;
    }
}

Что здесь важно:

• proxy_http_version 1.1 — полезно для корректной работы realtime-функций;
• не публикуйте контейнер напрямую наружу, если уже есть Nginx;
• не усложняйте конфиг старыми websocket-костылями из древних гайдов без необходимости.

Старые инструкции нередко тянут за собой отдельный websocket-порт и лишние ручные правила. Для современной установки это часто уже только источник ошибок.

Получение SSL (Let’s Encrypt)

Самый практичный путь — Let’s Encrypt. Бесплатно, нормально автоматизируется, не требует ручной возни с сертификатами каждые пару месяцев.

Типовой сценарий:

1. поднимаете Nginx с доменом;
2. проверяете, что домен смотрит на ваш сервер;
3. получаете сертификат через certbot;
4. настраиваете автопродление.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d vault.example.com

После этого проверьте продление. Ошибка многих новичков не в получении первого сертификата, а в том, что через 2–3 месяца всё просто перестаёт работать из-за просрочки.

Альтернативы (Caddy, Traefik)

Nginx — не единственный вариант.

• Caddy подойдёт, если хотите минимальную ручную настройку и автоматический HTTPS почти “из коробки”.
• Traefik удобен в Docker-окружении, когда у вас уже много контейнеров и нужна маршрутизация по labels.

Когда что выбирать:

• один сервис, нужен контроль и понятность — Nginx;
• хочется максимально простой TLS — Caddy;
• много контейнеров и вы уже живёте в Docker-экосистеме — Traefik.

Краткий вывод: если это ваш первый self-hosted парольный сервер, Nginx — самый предсказуемый старт.

Базовая настройка Vaultwarden

После первого запуска сервис уже может открываться, но это ещё не значит, что он настроен правильно. На этом шаге важно убрать открытые регистрации, задать домен, включить нормальную почту и защитить админку.

ENV-переменные

Минимальный набор переменных выглядит так:

• DOMAIN — полный внешний адрес сервиса;
• ADMIN_TOKEN — пароль/токен для доступа к админке;
• SIGNUPS_ALLOWED — разрешать ли открытые регистрации;
• SMTP_HOST, SMTP_FROM, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD — почта;

Пример блока environment:

environment:
  DOMAIN: "https://vault.example.com"
  ADMIN_TOKEN: "generate_a_long_random_secret"
  SIGNUPS_ALLOWED: "false"
  SMTP_HOST: "smtp.example.com"
  SMTP_FROM: "vault@example.com"
  SMTP_PORT: "587"
  SMTP_SECURITY: "starttls"
  SMTP_USERNAME: "vault@example.com"
  SMTP_PASSWORD: "strong_app_password"

Что подтверждено / что уже не стоит повторять:

Риск: не храните секреты в открытом виде в публичных репозиториях и не пересылайте compose-файл без удаления токенов и SMTP-паролей.

Регистрация пользователей и доступ

Лучший сценарий для личного или семейного сервера такой:

1. временно запускаете сервер с разрешённой регистрацией;
2. создаёте основной аккаунт;
3. после этого отключаете новые регистрации;
4. добавляете нужных людей через приглашения или вручную.

Открытая регистрация на публичном домене — почти всегда плохая идея. Это не форум и не SaaS с воронкой продаж. Тут лишние аккаунты — это лишняя поверхность атаки.

Если вы сравниваете разные решения перед развёртыванием, логично параллельно посмотреть лучшие бесплатные менеджеры паролей 2026, чтобы понять, в каком случае self-hosted Vaultwarden действительно имеет смысл, а в каком проще остаться на облачном сервисе.

Настройка SMTP (почта)

SMTP нужен не только “для красоты”. Без него у вас хуже работает восстановление доступа, подтверждение email и сценарий приглашений.

Базовые параметры:

• SMTP_HOST — адрес SMTP-сервера;
• SMTP_PORT — обычно 587 для STARTTLS или 465 для implicit TLS;
• SMTP_SECURITY — режим шифрования;
• SMTP_FROM — адрес отправителя;
• SMTP_USERNAME и SMTP_PASSWORD — учётные данные.

Практика выбора:

• для дома и малых инсталляций проще использовать внешний SMTP-провайдер;
• Gmail и похожие сервисы работают, но часто требуют app password и внимательной настройки;
• свой почтовый сервер даёт контроль, но заметно повышает сложность обслуживания.

На что чаще всего жалуются:

• не тот порт;
• не тот режим шифрования;
• провайдер режет авторизацию обычным паролем;
• неверный адрес отправителя, из-за чего письма уходят в спам.

Краткий вывод: если не хотите тратить время на отладку почты, используйте надёжный SMTP-сервис и app password, а не “обычный логин и пароль от ящика”.

Проверка и запуск в продакшене

Запустить контейнер — это половина дела. Продакшен начинается там, где вы проверяете доступ, резервные копии, обновление и восстановление после сбоя.

Проверка доступности

Перед реальным использованием пройдите короткий чек-лист:

• сайт открывается по HTTPS без предупреждений;
• вход через веб-интерфейс работает;
• мобильное приложение Bitwarden подключается к вашему серверу;
• письма отправляются;
• после входа нет странных ошибок синхронизации;
• данные переживают перезапуск контейнера.

Минимальная самопроверка:

docker compose ps
docker compose logs --tail=100
curl -I https://vault.example.com

Дополнительно проверьте вход в админ-панель и диагностику. Если что-то ломается, лог и diagnostics обычно быстрее выводят на причину, чем бессистемное редактирование compose-файла.

Типичные ошибки

Разбор рисков и ограничений:

• Self-hosted не значит “безопасно само по себе”. Ответственность за обновления и бэкапы на вас.
• Открытый в интернет сервер без ограничений по firewall — лишний риск.
• SQLite отлично подходит малым инстансам, но при росте нагрузки лучше заранее планировать переход на PostgreSQL.
• Домашний сервер удобен, пока не пропадает свет, интернет или DNS.

Обновление Vaultwarden

Обновлять контейнер просто, но только если перед этим сделан бэкап каталога /data. Это не тот сервис, где стоит надеяться на “да там и так ничего не случится”.

docker compose pull
docker compose down
docker compose up -d

Перед обновлением:

• сделайте копию /data;
• сохраните compose-файл;
• проверьте, не менялись ли важные параметры в release notes;
• после запуска проверьте вход, SMTP и синхронизацию.

Бэкап Vaultwarden:

tar -czf vaultwarden-backup-$(date +%F).tar.gz ./vw-data

Как перенести на другой сервер:

1. остановить контейнер на старом хосте;
2. скопировать папку /data;
3. перенести compose-файл;
4. запустить новый контейнер с тем же volume;
5. обновить DNS, если менялся IP.

SQLite vs PostgreSQL — когда менять БД:

• оставляйте SQLite, если у вас 1–5 пользователей и обычная домашняя нагрузка;
• думайте о PostgreSQL, если нужна более серьёзная эксплуатация, резервирование, много пользователей или вы уже строите нормальную серверную инфраструктуру.

FAQ

Как ограничить доступ к Vaultwarden?

Минимум — firewall, только 80/443 на прокси, запрет прямого доступа к контейнеру, отключённая открытая регистрация. Для домашнего сценария хороший апгрейд — VPN вместо полностью публичного входа.

Как подключить мобильные приложения Bitwarden?

В приложении Bitwarden меняете адрес сервера на свой домен Vaultwarden, после чего входите обычным способом. Главное, чтобы домен был доступен по HTTPS и корректно прописан в DOMAIN.

Нужна ли двухфакторная аутентификация?

Да, особенно если сервер доступен из интернета. Даже на личном инстансе 2FA сильно снижает риск компрометации учётной записи.

Можно ли спрятать сервер за Cloudflare?

Можно, но делать это стоит аккуратно и с пониманием, как именно работает ваш TLS, DNS и прокси-схема. Для части пользователей проще и чище выглядит вариант с VPN.

Можно ли масштабировать Vaultwarden?

Для обычного домашнего или малого офисного использования это редко нужно. Чаще упираются не в масштабирование приложения, а в качество БД, бэкапов, сети и обратного прокси.

Когда Vaultwarden — правильный выбор, а когда нет?

Он хорош, если вам нужен self-hosted менеджер паролей с контролем над данными и вы готовы обслуживать сервер. Если не хотите сами отвечать за обновления, резервные копии и почту — облачный менеджер паролей может быть разумнее.

Финальный вывод: для большинства пользователей рабочая формула выглядит так: Docker + compose + Nginx + Let’s Encrypt + закрытая регистрация + SMTP + регулярный бэкап /data. Если сделать именно так, Vaultwarden получается не “лабораторным проектом”, а нормальным повседневным сервисом.