Самостоятельный хостинг Vaultwarden на VPS с Docker Compose
Разверните защищённый менеджер паролей 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):
- Установи расширение Bitwarden из магазина дополнений твоего браузера
- На экране входа нажми на значок шестерёнки (или «Self-hosted» в новых версиях)
- Укажи Server URL —
https://vault.example.com - Сохрани и войди со своими учётными данными
Мобильное приложение (iOS, Android):
- Установи приложение Bitwarden из App Store или Google Play
- Перед входом нажми на значок шестерёнки на экране входа
- Укажи Server URL —
https://vault.example.com - Сохрани и войди
Десктопное приложение:
- Перед входом нажми на значок шестерёнки
- Укажи 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
Настройка доверенного контакта:
- Войди в веб-хранилище по адресу
https://vault.example.com - Перейди в Settings > Emergency Access
- Нажми Add emergency contact
- Введи email доверенного человека (у него должен быть аккаунт на твоём экземпляре Vaultwarden)
- Выбери уровень доступа:
- View: контакт может просматривать элементы хранилища (только чтение)
- Takeover: контакт может сбросить мастер-пароль и получить полный контроль
- Задай время ожидания (от 1 до 90 дней). Это задержка между запросом доступа и его фактическим получением. Ты получишь email-уведомление и сможешь отклонить запрос в течение этого периода.
- Нажми 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.
Готовы попробовать?
Разверните свой сервер за секунды. Linux, Windows или FreeBSD. →