Самостоятельный хостинг Vaultwarden на VPS с Docker Compose

11 мин чтения·Matthieu·self-hostingfail2bansecuritypassword-managerdocker-composedockervaultwarden|

Разверните защищённый менеджер паролей Vaultwarden на вашем VPS. Docker Compose с контейнерами в режиме только для чтения, fail2ban, SMTP для 2FA, резервное копирование и восстановление, экстренный доступ.

Vaultwarden хранит все твои пароли. Небрежный деплой хуже, чем отсутствие деплоя. Это руководство настраивает Vaultwarden на VPS с защищёнными Docker-контейнерами, fail2ban, SMTP для двухфакторной аутентификации и процедурой резервного копирования и восстановления.

Мы предполагаем, что Docker Engine и обратный прокси (Nginx или Caddy) уже работают на сервере. Если нет, начни с Docker в продакшене на VPS: что ломается и как это починить и Настройка Nginx как обратного прокси.

Что такое Vaultwarden и чем он отличается от Bitwarden?

Vaultwarden — это реализация серверного API Bitwarden на Rust. Работает как один Docker-контейнер, по умолчанию использует SQLite, потребляет около 50 МБ оперативной памяти в простое и полностью совместим со всеми официальными клиентами Bitwarden (расширения для браузеров, мобильные приложения, десктоп, CLI). Официальный self-hosted деплой Bitwarden требует более 11 контейнеров и минимум 4 ГБ RAM.

Vaultwarden Bitwarden Self-Hosted
Язык Rust C# (.NET)
Контейнеры 1 11+
RAM (простой) ~50 МБ ~2-4 ГБ
База данных SQLite (по умолчанию), MySQL, PostgreSQL MSSQL (обязательно)
Поддержка клиентов Bitwarden Полная Полная
SSO (OpenID Connect) С версии 1.35.0 Только план Enterprise
Официальная поддержка Сообщество Bitwarden Inc.
Лицензия AGPL-3.0 Проприетарная (SSPL для сервера)

Раньше Vaultwarden назывался bitwarden_rs. Если встретишь это имя в старых руководствах — это тот же проект.

Как развернуть Vaultwarden с Docker Compose на VPS?

Создай структуру каталогов для данных и конфигурации Vaultwarden. Все персистентные данные хранятся в одном каталоге, который потом будешь бэкапить.

mkdir -p /opt/vaultwarden/data
cd /opt/vaultwarden

Сгенерируй admin-токен с хешированием argon2. Никогда не храни admin-токен в открытом виде.

docker run --rm -it vaultwarden/server:1.35.4 /vaultwarden hash

Команда дважды запросит пароль, затем выведет строку PHC argon2id:

Generate an Argon2id PHC string using the 'bitwarden' preset:

Password:
Confirm Password:
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$S2mMOA8VnTtIOb3J8Gj9Jw$9cZ0YIKmGxfWEqSMKFMbORkBiW7hMGCls3SXAFXSIVE'

Сохрани эту строку. Она понадобится в файле окружения.

Создай файл секретов с ограниченными правами:

touch /opt/vaultwarden/.env
chmod 600 /opt/vaultwarden/.env

Отредактируй /opt/vaultwarden/.env, подставив свои значения:

DOMAIN=https://vault.example.com
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$your-hash-here'

SIGNUPS_ALLOWED=true
INVITATIONS_ALLOWED=true
EMERGENCY_ACCESS_ALLOWED=true
ORG_CREATION_USERS=all

SHOW_PASSWORD_HINT=false
IP_HEADER=X-Real-IP
LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=warn

SMTP_HOST=smtp.example.com
SMTP_FROM=vault@example.com
SMTP_PORT=587
SMTP_SECURITY=starttls
SMTP_USERNAME=vault@example.com
SMTP_PASSWORD=your-smtp-password

SHOW_PASSWORD_HINT=false не даёт утечь подсказкам к паролям тем, кто знает имя пользователя. IP_HEADER=X-Real-IP указывает Vaultwarden читать IP клиента из заголовка обратного прокси, что нужно fail2ban для блокировки правильного адреса.

Теперь создай Compose-файл.

Как захардить Docker-контейнер Vaultwarden?

Compose-файл ниже фиксирует версию образа, убирает все Linux capabilities, включает файловую систему корня в режиме «только для чтения», блокирует повышение привилегий и задаёт лимиты памяти. Это дефолтные настройки данного руководства, а не опциональные дополнения.

Создай /opt/vaultwarden/compose.yaml:

services:
  vaultwarden:
    image: vaultwarden/server:1.35.4
    container_name: vaultwarden
    restart: unless-stopped
    env_file: .env
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/alive"]
      interval: 30s
      timeout: 5s
      retries: 3
  • user: "1000:1000" запускает процесс от непривилегированного пользователя внутри контейнера. Нужно выставить владельца каталога данных: chown -R 1000:1000 /opt/vaultwarden/data.
  • cap_drop: ALL убирает все Linux capabilities. Vaultwarden они не нужны, потому что он слушает на порту 80 внутри контейнера (непривилегированный порт в данном контексте, поскольку маппинг делает Docker).
  • read_only: true запрещает контейнеру писать куда-либо, кроме явно смонтированных томов и tmpfs. Если Vaultwarden будет скомпрометирован, записать что-то в файловую систему контейнера не получится.
  • ports: "127.0.0.1:8080:80" привязывает порт только к localhost. Внешний трафик обрабатывает обратный прокси. Никогда не открывай Vaultwarden напрямую в интернет.
  • deploy.resources.limits.memory: 512M не даёт вышедшему из-под контроля процессу съесть всю оперативку сервера. Vaultwarden потребляет ~50 МБ в простое и ~100-150 МБ под нагрузкой. 512 МБ — с хорошим запасом.

Исправь владельца каталога данных и запусти контейнер:

chown -R 1000:1000 /opt/vaultwarden/data
docker compose up -d

[+] Running 1/1
 ✔ Container vaultwarden  Started

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

docker compose ps

NAME          IMAGE                       COMMAND       SERVICE       CREATED          STATUS                    PORTS
vaultwarden   vaultwarden/server:1.35.4   "/start.sh"   vaultwarden   Up 30 seconds (healthy)   127.0.0.1:8080->80/tcp

Статус (healthy) означает, что healthcheck прошёл. Посмотри логи на предмет ошибок запуска:

docker compose logs --tail 20

В логах видно, что Vaultwarden стартует на порту 80 внутри контейнера без ошибок.

Настройка обратного прокси

Обратный прокси перенаправляет HTTPS-трафик на 127.0.0.1:8080. Минимальный серверный блок Nginx:

server {
    listen 443 ssl;
    http2 on;
    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 525M;
    server_tokens off;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

client_max_body_size 525M разрешает загрузку вложений до лимита Bitwarden. server_tokens off скрывает версию Nginx из ответов, потому что раскрытие версии помогает атакующим целиться в известные уязвимости.

Начиная с Vaultwarden 1.29.0, WebSocket-трафик обслуживается через тот же порт, что и HTTP. Отдельный путь /notifications/hub для проксирования не нужен. Если в старых руководствах видишь WEBSOCKET_ENABLED — игнорируй. Эта переменная была объявлена устаревшей в 1.29.0 и удалена в 1.31.0.

Подробности по настройке Nginx — в Настройка Nginx как обратного прокси и Настройка Let's Encrypt SSL/TLS для Nginx на Debian 12 и Ubuntu 24.04.

Как настроить SMTP для Vaultwarden?

Vaultwarden нужен SMTP для отправки кодов верификации по email, писем настройки 2FA, приглашений в организации и уведомлений об экстренном доступе. Без SMTP не работают приглашения при регистрации, email-2FA и экстренный доступ.

Основные переменные окружения: SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME, SMTP_PASSWORD и SMTP_FROM. Используй SMTP_PORT=587 с SMTP_SECURITY=starttls для большинства провайдеров или SMTP_PORT=465 с SMTP_SECURITY=force_tls для неявного TLS.

Эти переменные уже включены в файл .env выше. После запуска контейнера протестируй отправку почты: зайди в веб-хранилище по адресу https://vault.example.com, создай аккаунт, перейди в Settings > Security > Two-step Login и включи email-2FA. Если код верификации пришёл — SMTP работает.

Проверь логи, если почта не отправляется:

docker compose logs | grep -i smtp

Типичные проблемы:

  • Ошибка аутентификации: перепроверь SMTP_USERNAME и SMTP_PASSWORD. Спецсимволы в пароле могут потребовать одинарных кавычек в файле .env.
  • Отказ соединения на порту 587: некоторые VPS-провайдеры блокируют исходящие порты 25 и 587 по умолчанию. Уточни у провайдера или попробуй порт 465 с force_tls.
  • Ошибка сертификата: TLS-сертификат SMTP-сервера должен быть валидным. Самоподписанные сертификаты требуют SMTP_ACCEPT_INVALID_CERTS=true (не рекомендуется для продакшена).
Переменная Назначение Пример
SMTP_HOST Хостнейм почтового сервера smtp.example.com
SMTP_PORT Порт подключения 587
SMTP_SECURITY Метод TLS starttls или force_tls
SMTP_FROM Адрес отправителя vault@example.com
SMTP_USERNAME Логин для аутентификации vault@example.com
SMTP_PASSWORD Пароль для аутентификации (хранится в .env, chmod 600)
SMTP_AUTH_MECHANISM Тип аутентификации (опционально) Login

Как защитить панель администратора Vaultwarden?

Панель администратора по адресу /admin позволяет управлять пользователями, просматривать конфигурацию и менять настройки. Она защищена ADMIN_TOKEN, который ты сгенерировал ранее. Хеш argon2 означает, что сырой токен никогда не хранится в .env-файле. Даже если кто-то прочитает файл, он получит хеш, а не пароль.

После первоначальной настройки (создание аккаунта, настройка SMTP, отключение регистрации) есть два варианта:

Вариант 1: Полностью отключить панель администратора. Удали или закомментируй ADMIN_TOKEN в .env и перезапусти:

docker compose down && docker compose up -d

Без установленного ADMIN_TOKEN эндпоинт /admin возвращает 404. Это самый безопасный вариант для однопользовательских инсталляций.

Вариант 2: Ограничить доступ через обратный прокси. Оставь панель активной, но заблокируй внешний доступ:

location /admin {
    allow 127.0.0.1;
    deny all;

    proxy_pass http://127.0.0.1:8080;
    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;
}

При необходимости заходи в панель через SSH-туннель:

ssh -L 8888:127.0.0.1:443 user@your-vps

Затем открой https://127.0.0.1:8888/admin в браузере.

Отключение публичной регистрации

Когда аккаунт создан, отключи открытую регистрацию. Отредактируй /opt/vaultwarden/.env:

SIGNUPS_ALLOWED=false

Перезапусти контейнер:

cd /opt/vaultwarden && docker compose down && docker compose up -d

Новые пользователи по-прежнему смогут присоединяться через приглашения организации, если INVITATIONS_ALLOWED=true. Это позволяет добавлять членов команды, не открывая регистрацию для всех.

Как настроить fail2ban для Vaultwarden в Docker?

Fail2ban мониторит лог-файл Vaultwarden на предмет неудачных попыток входа и банит IP-адреса нарушителей. Поскольку Vaultwarden работает в Docker, правило бана должно использовать цепочку iptables DOCKER-USER. Стандартные правила цепочки INPUT не влияют на трафик, маршрутизируемый Docker.

Контейнер Vaultwarden пишет логи в /opt/vaultwarden/data/vaultwarden.log (маппинг с /data/vaultwarden.log внутри контейнера), потому что мы задали LOG_FILE=/data/vaultwarden.log в окружении.

Подробное руководство по установке fail2ban — в Установка и настройка Fail2Ban на Linux VPS.

Фильтр логинов

Создай /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Фильтр панели администратора

Создай /etc/fail2ban/filter.d/vaultwarden-admin.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Invalid admin token\. IP: <ADDR>.*$
ignoreregex =

Конфигурация jail

Создай /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
action = iptables-allports[name=vaultwarden, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify

[vaultwarden-admin]
enabled = true
port = http,https
filter = vaultwarden-admin
action = iptables-allports[name=vaultwarden-admin, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify
Параметр Значение Почему
chain DOCKER-USER Docker обходит цепочку INPUT. Правила должны быть в DOCKER-USER, чтобы влиять на трафик контейнеров.
maxretry 3 Три неудачные попытки — бан. Легитимные пользователи редко ошибаются больше двух раз.
bantime 14400 Бан на четыре часа. Достаточно, чтобы отпугнуть брутфорс, но не заблокировать навсегда того, кто просто опечатался.
findtime 14400 Считает неудачи в окне четырёх часов.
backend pyinotify Мониторинг логов на основе файлов. Бэкенд systemd по умолчанию не может читать лог-файлы Docker-контейнеров.

Перезапусти fail2ban и проверь jail:

systemctl restart fail2ban
fail2ban-client status vaultwarden

Status for the jail: vaultwarden
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /opt/vaultwarden/data/vaultwarden.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Протестируй регулярное выражение на реальном формате лога:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Если неудачных логинов ещё нет, вывод покажет 0 matched. Это нормально. Спровоцируй ошибочный вход через веб-хранилище и запусти снова, чтобы убедиться, что regex работает.

Как подключить расширения браузера и мобильные приложения к Vaultwarden?

Все официальные клиенты Bitwarden работают с Vaultwarden. Единственное изменение — указать URL твоего сервера вместо bitwarden.com.

Расширение браузера (Chrome, Firefox, Safari):

  1. Установи расширение Bitwarden из магазина дополнений твоего браузера
  2. На экране входа нажми на значок шестерёнки (или «Self-hosted» в новых версиях)
  3. Укажи Server URL — https://vault.example.com
  4. Сохрани и войди со своими учётными данными

Мобильное приложение (iOS, Android):

  1. Установи приложение Bitwarden из App Store или Google Play
  2. Перед входом нажми на значок шестерёнки на экране входа
  3. Укажи Server URL — https://vault.example.com
  4. Сохрани и войди

Десктопное приложение:

  1. Перед входом нажми на значок шестерёнки
  2. Укажи Server URL — https://vault.example.com

CLI:

bw config server https://vault.example.com
bw login

Все клиенты синхронизируются через твой экземпляр Vaultwarden. Данные хранилища никогда не попадают на серверы Bitwarden.

Как настроить экстренный доступ в Vaultwarden?

Экстренный доступ (Emergency Access) позволяет доверенному контакту получить доступ к твоему хранилищу или взять его под контроль, если ты стал недоступен. Требуется настроенный SMTP, так как Vaultwarden отправляет уведомления по email в процессе.

Убедись, что функция включена в .env:

EMERGENCY_ACCESS_ALLOWED=true

Настройка доверенного контакта:

  1. Войди в веб-хранилище по адресу https://vault.example.com
  2. Перейди в Settings > Emergency Access
  3. Нажми Add emergency contact
  4. Введи email доверенного человека (у него должен быть аккаунт на твоём экземпляре Vaultwarden)
  5. Выбери уровень доступа:
    • View: контакт может просматривать элементы хранилища (только чтение)
    • Takeover: контакт может сбросить мастер-пароль и получить полный контроль
  6. Задай время ожидания (от 1 до 90 дней). Это задержка между запросом доступа и его фактическим получением. Ты получишь email-уведомление и сможешь отклонить запрос в течение этого периода.
  7. Нажми Save

Доверенный контакт получит письмо с приглашением. После принятия он отобразится как ожидающий экстренный контакт. Время ожидания работает как предохранитель: если ты не ответишь в течение настроенного количества дней, доступ предоставляется автоматически.

Для личного хранилища 7 дней ожидания с доступом View — разумный выбор. Для инфраструктуры команды стоит рассмотреть более короткие сроки.

Как сделать бэкап и восстановить экземпляр Vaultwarden?

Vaultwarden хранит всё в каталоге /data: базу данных SQLite (db.sqlite3), вложения, кэш иконок и конфигурацию. Правильный бэкап захватывает всё это согласованно.

Базу данных SQLite нужно бэкапить через sqlite3 .backup, а не копированием файла напрямую. Копирование активного SQLite-файла может привести к повреждённому бэкапу, если во время копирования произойдёт запись. Команда .backup создаёт консистентный снимок.

Что бэкапить Расположение Метод Частота
База данных SQLite /opt/vaultwarden/data/db.sqlite3 sqlite3 .backup Ежедневно
Вложения /opt/vaultwarden/data/attachments/ rsync или cp -a Ежедневно
Кэш иконок /opt/vaultwarden/data/icon_cache/ Пропустить (регенерируется автоматически) -
Файл окружения /opt/vaultwarden/.env cp При изменении
Compose-файл /opt/vaultwarden/compose.yaml cp При изменении

Скрипт резервного копирования

Для автоматических бэкапов скрипт использует age с файлом ключа получателя. Это исключает интерактивные запросы пароля, чтобы скрипт мог работать из cron.

Сгенерируй пару ключей (один раз):

apt install age
age-keygen -o /opt/vaultwarden/backup-key.txt
chmod 600 /opt/vaultwarden/backup-key.txt

Команда выведет публичный ключ в stdout. Сохрани его в файл получателя:

age-keygen -y /opt/vaultwarden/backup-key.txt > /opt/vaultwarden/backup-key.pub

Храни копию backup-key.txt (приватный ключ) за пределами сервера. Он нужен для расшифровки бэкапов. Потеряешь этот ключ — зашифрованные бэкапы станут невосстановимыми.

Создай /opt/vaultwarden/backup.sh:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/opt/vaultwarden/backups"
DATA_DIR="/opt/vaultwarden/data"
DATE=$(date +%Y-%m-%d_%H%M)
BACKUP_FILE="${BACKUP_DIR}/vaultwarden-${DATE}.tar"
RECIPIENT="/opt/vaultwarden/backup-key.pub"

mkdir -p "${BACKUP_DIR}"

# Back up SQLite database consistently
sqlite3 "${DATA_DIR}/db.sqlite3" ".backup '${BACKUP_DIR}/db-${DATE}.sqlite3'"

# Package database + attachments + config
tar cf "${BACKUP_FILE}" \
  -C "${BACKUP_DIR}" "db-${DATE}.sqlite3" \
  -C "${DATA_DIR}" attachments/ \
  -C /opt/vaultwarden .env compose.yaml 2>/dev/null || true

# Encrypt with age recipient key (non-interactive)
age -R "${RECIPIENT}" -o "${BACKUP_FILE}.age" "${BACKUP_FILE}"

# Clean up unencrypted files
rm -f "${BACKUP_FILE}" "${BACKUP_DIR}/db-${DATE}.sqlite3"

# Remove backups older than 30 days
find "${BACKUP_DIR}" -name "*.age" -mtime +30 -delete

echo "Backup complete: ${BACKUP_FILE}.age"

chmod 700 /opt/vaultwarden/backup.sh

Для ежедневных автоматических бэкапов добавь задание cron:

echo "0 3 * * * root /opt/vaultwarden/backup.sh >> /var/log/vaultwarden-backup.log 2>&1" > /etc/cron.d/vaultwarden-backup
chmod 644 /etc/cron.d/vaultwarden-backup

Для внесерверных копий отправь зашифрованный бэкап на удалённый сервер или в объектное хранилище:

rsync -az /opt/vaultwarden/backups/*.age backup-user@remote-server:/backups/vaultwarden/

Процедура восстановления

Бэкап, который ты ни разу не восстанавливал, — это бэкап, которому нельзя доверять. Полная процедура:

# Stop the container
cd /opt/vaultwarden && docker compose down

# Decrypt the backup
age -d -i /opt/vaultwarden/backup-key.txt -o /tmp/vaultwarden-restore.tar /opt/vaultwarden/backups/vaultwarden-2026-03-20_0300.tar.age

# Extract
mkdir -p /tmp/vaultwarden-restore
tar xf /tmp/vaultwarden-restore.tar -C /tmp/vaultwarden-restore

# Replace the database (delete WAL files first)
rm -f /opt/vaultwarden/data/db.sqlite3-wal /opt/vaultwarden/data/db.sqlite3-shm
cp /tmp/vaultwarden-restore/db-2026-03-20_0300.sqlite3 /opt/vaultwarden/data/db.sqlite3
chown 1000:1000 /opt/vaultwarden/data/db.sqlite3

# Restore attachments
rsync -a /tmp/vaultwarden-restore/attachments/ /opt/vaultwarden/data/attachments/
chown -R 1000:1000 /opt/vaultwarden/data/attachments/

# Start the container
docker compose up -d

# Clean up
rm -rf /tmp/vaultwarden-restore /tmp/vaultwarden-restore.tar

Перед восстановлением нужно удалить файлы WAL (Write-Ahead Log) и SHM. Эти файлы принадлежат старому состоянию базы данных. Запуск Vaultwarden с восстановленной базой, но устаревшими WAL-файлами приводит к повреждению данных.

После восстановления зайди в веб-хранилище и убедись, что все записи на месте.

Как безопасно обновить Vaultwarden?

Привяжи образ к конкретному тегу версии (мы использовали 1.35.4). Никогда не используй :latest в продакшене — ты не сможешь отследить изменения и надёжно откатиться.

Для обновления:

cd /opt/vaultwarden

# Back up first
./backup.sh

# Pull the new version
docker compose pull

# Recreate the container
docker compose up -d

Перед pull отредактируй compose.yaml, чтобы сменить тег образа на новую версию. Проверь заметки о релизе на предмет ломающих изменений.

docker compose logs --tail 30

Если обновление что-то сломало, восстановись из бэкапа:

# Revert compose.yaml to the old version tag
docker compose down
# Follow the restore procedure above
docker compose up -d

Что-то пошло не так?

Контейнер сразу останавливается:

docker compose logs

Ищи ошибки прав доступа. Директива user: 1000:1000 требует соответствующего владельца на /opt/vaultwarden/data. Выполни chown -R 1000:1000 /opt/vaultwarden/data и попробуй снова.

Не удаётся зайти в веб-хранилище:

Проверь, что обратный прокси пробрасывает трафик на 127.0.0.1:8080:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/alive

Ответ 200 означает, что Vaultwarden работает. Проблема в конфигурации обратного прокси.

Fail2ban не банит:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Если regex не совпал ни с одной строкой, проверь, что LOG_FILE=/data/vaultwarden.log задан в .env и что лог-файл существует по пути /opt/vaultwarden/data/vaultwarden.log.

Письма не отправляются:

docker compose logs | grep -i "smtp\|mail\|email"

Проверь, что VPS разрешает исходящие соединения на SMTP-порту:

nc -zv smtp.example.com 587

Ошибки блокировки базы данных:

Это может случиться, если копировать файл базы данных, пока Vaultwarden работает. Всегда используй sqlite3 .backup для бэкапов и всегда останавливай контейнер перед восстановлением.

Расположение логов:

# Application logs
docker compose logs -f

# Log file (if LOG_FILE is set)
tail -f /opt/vaultwarden/data/vaultwarden.log

# Fail2ban logs
journalctl -u fail2ban -f

О безопасности Docker-контейнеров за рамками этого руководства — в Усиление безопасности Docker: Rootless-режим, Seccomp, AppArmor на VPS. О стратегиях бэкапа для всех Docker-сервисов — в Резервное копирование и восстановление томов Docker на VPS.

Авторское право 2026 Virtua.Cloud. Все права защищены. Данный контент является оригинальным произведением команды Virtua.Cloud. Воспроизведение, повторная публикация или распространение без письменного разрешения запрещены.

Готовы попробовать?

Разверните свой сервер за секунды. Linux, Windows или FreeBSD.

Смотреть тарифы VPS