Самостоятельный хостинг 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/1Container 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 URLhttps://vault.example.com
  4. Сохрани и войди со своими учётными данными

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

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

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

  1. Перед входом нажми на значок шестерёнки
  2. Укажи Server URLhttps://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.

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