Самостоятельно разместите Bitwarden на анонимном VPS

Команда HushVPS · Обновлено 2026 · 8 мин чтения

Ваше хранилище паролей — самый чувствительный аккаунт, который у вас есть. Взломав его, злоумышленник получает вашу почту, ваш банк, ваших поставщиков идентификации — всё, что ниже по цепочке. Поэтому вопрос о том, где живёт это хранилище, не академичен. Если вы хотите самостоятельно разместить Bitwarden на VPS без KYC, вы выбираете держать зашифрованную базу данных на оборудовании, которым управляете, оплаченном анонимно, вместо облака третьей стороны, привязанного к вашему юридическому имени. Это руководство объясняет, почему этот компромисс имеет смысл, как настройка работает на высоком уровне и где анонимный хостинг закрывает разрыв, который оставляет обычный self-хостинг.

Зачем вообще самостоятельно размещать менеджер паролей

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

  • Вы убираете цель. Управляемый провайдер сейфов — это приманка высокой ценности; миллионы зашифрованных блобов в одном месте привлекают решительных атакующих. Ваш единственный самостоятельный экземпляр — гораздо менее интересная добыча.
  • Вы контролируете доступность. Никакой блокировки аккаунта, никаких неожиданных изменений политики, никакой блокировки по региону. Сервис работает, пока работает ваш сервер.
  • Вы владеете метаданными. Даже при шифровании с нулевым разглашением провайдер все равно видит ваши IP-адреса входа, временные метки, отпечатки устройств и платежную идентичность. Self-хостинг оставляет эту телеметрию на вашей собственной машине.

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

Bitwarden против Vaultwarden: что вы на самом деле запускаете

Есть два способа самостоятельно разместить экосистему Bitwarden. Первый — официальный self-хостинг сервер от Bitwarden, который функционально полон, но тяжелее — он ожидает несколько контейнеров и больше RAM, чем комфортно даёт маленький VPS. Второй, и тот, который выбирают большинство заботящихся о приватности self-хостеров, — это Vaultwarden, неофициальный сервер на Rust, который говорит на том же API, что и официальные клиенты. Он счастливо работает в одном контейнере на боксе с 1 vCPU / 2 ГБ, так что он вписывается в наш начальный тариф с запасом.

Важная деталь: поскольку Vaultwarden реализует API Bitwarden, вы по-прежнему используете официальные, проверенные приложения Bitwarden и расширения браузера на своих устройствах. Вы заменяете только серверную часть. Ваш сейф остается зашифрованным сквозным шифрованием; сервер просто хранит и синхронизирует зашифрованный блоб. В этом вся привлекательность — безопасность официального клиента, контроль self-хостинга.

Что нужно перед началом

Требования скромные. Вам нужен небольшой Linux VPS с root-доступом, доменное имя (или поддомен), указывающее на его IP, и около двадцати минут. Ресурсный след Vaultwarden крошечный, поэтому наш самый маленький тариф Phantom — 1 vCPU, 2 ГБ RAM и 30 ГБ NVMe более чем достаточен для личного или семейного сейфа. Хранилище почти не двигается; сейф с сотнями записей и вложений измеряется мегабайтами.

Разверните сервер, запишите IPv4 и IPv6-адреса, которые мы вам выдадим, и создайте запись AAAAA) для vault.yourdomain.tld, указывающую на них. Это единственная внешняя зависимость. Всё остальное живёт на самом сервере.

Высокоуровневая настройка

Не открывайте порт контейнера Vaultwarden напрямую в интернет. Стандартный безопасный подход — обратный прокси с TLS перед ним. Вот общая схема, без превращения в скрипт для копирования, которому не стоит слепо доверять.

1. Сначала защитите сервер

Перед установкой чего-либо обновите систему, создайте непривилегированного пользователя и отключите вход по SSH с паролем в пользу входа только по ключу. Включите брандмауэр (ufw или nftables), разрешающий только порты 22, 80 и 443. Это базовая гигиена, занимает две минуты; пропуск этого шага — путь к взлому self-хостинга.

2. Разверните Vaultwarden в контейнере

Установите Docker, затем запустите официальный образ Vaultwarden, смонтировав его каталог данных в постоянный том на хостинг-провайдере. Этот том — обычно /vw-data — содержит базу данных SQLite, вложения и ключи RSA. Это единственное, что вы никогда не должны терять, поэтому резервному копированию посвящён отдельный раздел ниже.

3. Установите обратный прокси и HTTPS перед сервисом

Используйте Caddy или Nginx в качестве публичного слоя. Caddy — простой путь: он автоматически получает и обновляет сертификат Let's Encrypt, так что ваш сейф будет доступен по HTTPS без ручного управления сертификатами. Направьте прокси на внутренний порт Vaultwarden — и готово. Менеджер паролей никогда не должен быть доступен по обычному HTTP — расширения браузера в любом случае откажутся с ним работать.

4. Закройте дверь за собой

После того как ваш собственный аккаунт создан, установите SIGNUPS_ALLOWED=false, чтобы никто другой не мог зарегистрироваться в вашем экземпляре. Если вы хотите членов семьи, приглашайте их явно или используйте страницу администратора (защищённую собственным токеном) для управления пользователями. Открытая регистрация на публичном хранилище — это приглашение, которое вы не хотите отправлять.

Резервное копирование: та часть, которую пропускают

Self-хостинг означает, что теперь вы отвечаете за резервное копирование. Хорошая новость в том, что всё состояние Vaultwarden — это один каталог данных, а база данных — это один файл SQLite. Разумный порядок действий выглядит так:

  • Делайте ночной снапшот каталога данных — используйте команду SQLite .backup, а не копирование живого файла, чтобы никогда не захватить наполовину записанную базу данных.
  • Зашифруйте резервную копию до того, как она покинет сервер (age или GPG), потому что она содержит ваш зашифрованный сейф и его ключи.
  • Отправьте зашифрованный архив за пределы сервера: на второй сервер HushVPS, в объектное хранилище или на вашу собственную машину по SSH.
  • Проверьте восстановление хотя бы один раз. Резервная копия, которую вы никогда не восстанавливали, — это надежда, а не план.

Поскольку сам сейф уже зашифрован вашим мастер-паролем, внешняя копия не создаёт новой угрозы, если вы также шифруете передачу и хранение. Ремень и подтяжки.

Укрепление работающего сервиса

Несколько привычек сохранят ваш self-хостинговый сейф скучным, а именно это вам и нужно:

  • Обновляйтесь по расписанию. Регулярно загружайте последний образ Vaultwarden и поддерживайте ОС хостинг-провайдера в актуальном состоянии. Unattended-upgrades занимается ОС; простая cron или политика Watchtower занимается контейнером.
  • Включите двухфакторную аутентификацию для каждого аккаунта. Даже self-хостинг экземпляр выигрывает от этого enormously — это превращает утечку мастер-пароля из катастрофы в почти промах.
  • Рассмотрите возможность скрыть его за VPN. Если только вы и ваша семья используете хранилище, вы можете привязать его к интерфейсу WireGuard, чтобы он вообще не был доступен из открытого интернета. В сочетании с VPS без логов, который не хранит записи о доступе, поверхность, которую атакующий может увидеть, сокращается почти до нуля.
  • Ограничьте частоту запросов и мониторьте. Vaultwarden поддерживает ограничение попыток входа; включите его. Следите за логами на предмет повторяющихся неудачных попыток.

Разверните сервер для вашего сейфа за минуты

Vaultwarden помещается в наш самый маленький тариф. Без ID, без карты — оплата Monero и root-доступ на сервере, который не привязан к вашему имени.

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

Почему это важно делать на анонимном хостинге без KYC

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

Анонимный хостинг без KYC закрывает этот последний пробел. Когда нет проверки личности, нет карты в файле, и Monero оплачивает счет, провайдер, управляющий оборудованием, не может связать сервер, хранящий ваши самые чувствительные данные, с вами через платежную запись. В аккаунте нечего подвергать субпене, продавать, утекать или передавать — потому что это никогда не собиралось. В этом разница между приватностью в приложении и приватностью во всем стеке. Наша более подробная статья о запуске собственных приватных сервисов на анонимном VPS рассматривает ту же логику для почты и облачного хранилища.

Чтобы было ясно, что это делает и чего не делает: анонимный хостинг защищает вас от того, чтобы уровень хостинга стал бумажным следом. Это не делает вас невидимым и не оправдывает ничего незаконного — HushVPS — офшорный провайдер, работающий в рамках закона, и минимизирующий данные, и наша политика допустимого использования по-прежнему запрещает вредоносное ПО, спам и сетевые атаки. Цель проста: сохранить ваше хранилище паролей вашим, на оборудовании, которое никто не может тривиально связать с вашей личностью, с резервным копированием и защитой, чтобы оно оставалось скучным годами.

Кратко

Self-хостинг Bitwarden — на практике Vaultwarden — помещает самый важный аккаунт, которым вы владеете, на машину, которую вы контролируете, используя те же проверенные клиенты, которым вы уже доверяете. Сделайте это правильно: заблокируйте коробку, завершите TLS с помощью обратного прокси, отключите открытые регистрации, делайте резервное копирование каталога данных вне сайта с шифрованием и поддерживайте все в актуальном состоянии. Сделайте это на VPS без KYC, оплачиваемом Monero, и вы также устраните платежный след, который в противном случае связал бы это хранилище с вашим именем. Приватность на обоих концах стека — именно там и должен жить менеджер паролей.