Vaultwarden чи Bitwarden: що обрати для VPS

Що насправді являють собою self-hosted Vaultwarden і Bitwarden

Vaultwarden і self-hosted Bitwarden — це вибір між двома серверами, які підтримують один і той самий API клієнтів, а не вибір між двома менеджерами паролів. Власний стек Bitwarden працює приблизно в дюжині контейнерів за nginx, зберігає всі дані в Microsoft SQL Server і прив’язаний до installation ID, який ви реєструєте за допомогою email-адреси. Vaultwarden — це неофіційна реалізація API клієнтів Bitwarden, написана на Rust. Вона працює як один контейнер з одним файлом SQLite. Розширення браузера та телефон не можуть відрізнити ці сервери, оскільки обидва відповідають на однакові endpoints.

Шифрування в обох випадках однакове. Клієнти Bitwarden шифрують vault до того, як будь-які дані залишають пристрій. Тому сервер зберігає blobs, які не може прочитати. Формат vault в обох випадках належить Bitwarden. Відрізняються вимоги до орендованої машини, відповідальні за супровід коду, платні функції та дані, які потрібно резервувати.

У README Vaultwarden прямо зазначено його статус: "This project is not associated with Bitwarden or Bitwarden, Inc." Це волонтерський проєкт без служби підтримки та гарантій. Один з активних супроводжувачів працює в Bitwarden і робить внески у вільний від основної роботи час. Це свідчить про доброзичливе ставлення, але не є схваленням проєкту.

Три стеки, які можна встановити

У більшості порівнянь не враховано, що Bitwarden випускає два різні продукти для self-hosted розгортання.

Bitwarden standard. Розгортання від виробника, яке виконується shell-скриптом.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

Інсталятор запитує доменне ім’я, чи потрібно отримати сертифікат Let’s Encrypt, назву бази даних, а також installation ID і key, які можна отримати в https://bitwarden.com/host, вказавши адресу електронної пошти. ./bitwarden.sh start завантажує образи та запускає стек. Bitwarden вказує 2 GB RAM і 12 GB сховища як мінімальні вимоги, 4 GB RAM і 25 GB сховища як рекомендовані, а також Docker Engine 26 або новішої версії з Compose plugin. Для бази даних використовується образ MSSQL Express. Це видання обмежує розмір реляційної бази даних 10 GB, якщо не підключити зовнішню базу даних.

Bitwarden lite. Це розгортання, яке раніше називалося Bitwarden Unified. У грудні 2025 року воно вийшло з beta та отримало нову назву. Один контейнер застосунку плюс база даних на ваш вибір:

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: ghcr.io/bitwarden/lite
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden
  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql
volumes:
  bitwarden:
  data:

Підтримуються MariaDB або MySQL, PostgreSQL, SQLite і MSSQL. Потрібно 200 MB RAM і 1 GB сховища. Документація Bitwarden містить два застереження. Цей варіант призначений для особистого використання та домашніх лабораторій, а не для бізнесу. Автоматичні резервні копії бази даних не створюються, тому їх потрібно налаштувати самостійно.

Vaultwarden. Один контейнер безпосередньо з README проєкту:

docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

Рядок публікації прив’язує порт 8000 лише до loopback-інтерфейсу. Це зроблено навмисно. Vaultwarden надає звичайний HTTP і очікує, що reverse proxy попереду завершить TLS (transport layer security). У цьому випадку TLS є обов’язковим: web vault виконує шифрування за допомогою WebCrypto API браузера, а браузери надають цей API лише в secure context. Тому через звичайний http сторінка входу завершується помилкою в браузері ще до того, як запит надходить на сервер. У повному посібнику зі встановлення Vaultwarden описано налаштування проксі та сертифіката.

Скільки RAM використовує Vaultwarden порівняно із self-hosted Bitwarden?

Мінімальні вимоги постачальника показують, за якого обсягу ресурсів інсталятор відмовляється запускатися, а не фактичне споживання програмного забезпечення. Наведені нижче значення отримано з docker stats --no-stream на простоюючих інсталяціях: по одному користувачу, невелике сховище та без вкладень, на сервері з Ubuntu 24.04 і 4 GB RAM. Розмір на диску — це обсяг образів і каталогу даних після першого успішного запуску.

[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

Vaultwarden у простої використовував 58 MB в одному контейнері. Стандартний стек Bitwarden використовував близько 2,400 MB у 12 контейнерах, причому більша частина припадала на контейнер MSSQL. Bitwarden lite використовував 470 MB разом зі своїм контейнером MariaDB. Перш ніж покладатися на ці значення, виконайте ту саму команду на власному сервері, оскільки вони залежать від кількості користувачів, вкладень і синхронізаційного трафіку, а робочий набір MSSQL збільшується в міру роботи.

Практичний висновок для невеликого VPS: Vaultwarden із SQLite стабільно працює на тарифі з 1 GB RAM, а стандартний стек Bitwarden там не запуститься. На тарифі з 2 GB RAM стандартний стек відповідає задокументованій мінімальній вимозі й залишає операційній системі дуже мало пам’яті, тому спрацьовування засобу ядра для завершення процесів через нестачу пам’яті стає реальною подією. Коли це відбувається, dmesg виводить рядок із назвою завершеного процесу; у цьому стеку ним зазвичай є sqlservr. Для стандартного розгортання виділіть 4 GB RAM.

Які платні функції безкоштовні у Vaultwarden?

Запуск сервера Bitwarden нічого не коштує, але платні функції залишаються недоступними, доки ви не завантажите файл ліцензії. Він потрібен для індивідуальних Premium-облікових записів і для кожного платного рівня організації (Families, Teams, Enterprise). Завантажити його можна з хмарного вебсховища: для індивідуального облікового запису відкрийте Settings, потім Subscription, а для організації — Admin Console, потім Billing і Subscription. Після цього завантажте файл у власний інстанс. Ліцензії організацій випускаються для ідентифікатора інсталяції, що зберігається у ./bwdata/env/global.override.env. Отже, self-hosted організація все одно має платну підписку та взаємодіє з хмарою Bitwarden для розрахунків.

Vaultwarden вмикає ці самі функції без ліцензії та підписки. У вікі проєкту перелічено такі функції:

• організації, колекції та групи
• вкладення файлів
• двоетапний вхід через email, Duo, YubiKey і FIDO2
• Emergency Access
• Bitwarden Send
• персональні API-ключі
• SSO через OpenID Connect

SSO — найновіша з цих функцій. Вона налаштовується за допомогою SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID і SSO_CLIENT_SECRET. SSO автентифікує лише вхід. У вікі прямо зазначено, що master password все одно потрібен і не контролюється вашим identity provider, оскільки саме з цього пароля виводиться ключ для розшифрування сховища. Укажіть у SSO_AUTHORITY discovery issuer для self-hosted identity provider Authentik. Користувачі входитимуть через нього, а потім розблоковуватимуть сховище за допомогою master password. Значення має збігатися з полем issuer, яке повертає discovery endpoint, без суфікса /.well-known/openid-configuration наприкінці.

Vaultwarden не надає вам постачальника. Bitwarden має сертифікації SOC 2 Type 2 та ISO 27001, публікує звіти незалежних аудитів і підтримує приватну bug bounty-програму на HackerOne. Вони стосуються коду та сервісу Bitwarden, а не сервера, який ви встановили. Проте якщо аудитор очікує, що за вашим password manager стоятиме конкретний постачальник, використання волонтерської реалізації може бути складним для обґрунтування.

Чи працюють офіційні застосунки Bitwarden із Vaultwarden?

Так. Vaultwarden реалізує API клієнта, тому з ним працюють розширення для браузерів, настільні та мобільні застосунки, а також вбудований вебсховищe. У кожному клієнті потрібно вказати URL self-hosted сервера на екрані середовища до входу, а не після нього.

Для push-сповіщень у мобільних застосунках потрібне додаткове налаштування. Без них застосунок синхронізується після відкриття або за власним таймером. Тому пароль, змінений на ноутбуці, не з’явиться на телефоні, доки ви не відкриєте застосунок. Vaultwarden може використовувати push relay Bitwarden. Для цього потрібні installation ID і key зі самої сторінки https://bitwarden.com/host, яку використовує офіційний інсталятор.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

Для серверів у регіоні EU також потрібні PUSH_RELAY_URI=https://api.bitwarden.eu і PUSH_IDENTITY_URI=https://identity.bitwarden.eu. У wiki описано дві особливості, про які варто знати, перш ніж витрачати годину на діагностику. Застосунок, встановлений із F-Droid або Neo Store, не має підтримки Firebase і ніколи не отримуватиме push-сповіщення, незалежно від налаштувань сервера. У застосунку, який підключався до Vaultwarden до версії 1.30.2, потрібно очистити дані, щоб він зареєстрував push-токен.

Наскільки безпечною є повторна реалізація?

Історія аудитів Bitwarden довга й публічна. Cure53 перевіряла його у 2018, 2021, 2022 і 2023 роках. IOActive і Mandiant перевіряли клієнти у 2024 році, Fracture Labs проводила оцінювання вебзастосунку та мережі протягом 2024 і 2025 років, Unit 42 оцінювала мобільні застосунки у 2025 році, а Applied Cryptography Group при ETH Zurich перевіряла криптографію у 2025 році.

Vaultwarden також перевіряли зовнішні фахівці, хоча дехто вважає, що ніхто цього не робить. Федеральне відомство з інформаційної безпеки Німеччини (BSI) залучило mgm security partners для тестування Vaultwarden у період із лютого до травня 2024 року в межах проєкту аналізу коду Caos 3.0. За результатами перевірки два висновки отримали високий рівень критичності. Окремо ERNW повідомила про обхід автентифікації у версіях до 1.32.5 включно (CVE-2024-55225); проблему виправили в листопаді 2024 року. У версії 1.37.0, випущеній у липні 2026 року, виправили SSRF (server side request forgery) через endpoint піктограм, доступ до cipher іншої організації та обхід політики організації під час імпорту каталогів.

Ця історія свідчить, що в проєкті працює процес розкриття вразливостей. Вона також указує на компонент, який регулярно фігурує у звітах: сторінку адміністратора. Тому ставтеся до цієї сторінки як до чутливого компонента. Вона залишається вимкненою, якщо не задано ADMIN_TOKEN, а замість токена у відкритому вигляді слід зберігати його хеш.

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

Ця команда виводить рядок Argon2 PHC (password hashing competition format), який потрібно вставити в ADMIN_TOKEN. Увімкніть HTTPS до ввімкнення сторінки адміністратора, оскільки токен передається в запиті, а токен у відкритому вигляді через незашифроване HTTP-з’єднання може прочитати будь-хто на мережевому шляху. За можливості не відкривайте /admin для публічного інтернету та поєднайте це зі стандартним hardening хоста, зокрема обмеженням доступу до SSH на сервері.

Що ламається після змін в офіційному API

Цей ризик часто недооцінюють. Bitwarden випускає клієнти, і ці клієнти автоматично оновлюються з магазинів застосунків протягом ночі. Vaultwarden має їм відповідати. Якщо випуск клієнта змінює контракт API, неоновлений Vaultwarden стикається з клієнтом, який уже перейшов на нову версію. Через це на пристроях, яких ви не змінювали, можуть початися збої входу або синхронізації.

У примітках до випуску є конкретний приклад. У Vaultwarden 1.37.0 зазначено: "Це оновлення потрібне для підтримки клієнтів версії 2026.7.0 і новіших; оновіть систему, перш ніж повідомляти про будь-які проблеми з ними." Станом на August 2026 поточним є випуск 1.37.1, опублікований 29 July 2026.

Цього достатньо, щоб уникати неочікуваних проблем. Замість latest зафіксуйте певний тег образу. Тоді автоматичне отримання образу не оновить сервер о 3am без вашого відома. Також стежте за стрічкою випусків і оновлюйте систему навмисно, спочатку читаючи примітки. Саме там, і більше ніде, описують несумісні зміни. Наприклад, версія 1.35.5 під час оновлення анулювала всі наявні токени запам’ятовування двофакторної автентифікації. Через це користувачів було виведено з облікового запису, хоча вони вважали, що зберегли цей крок.

У стандартному розгортанні Bitwarden є дзеркальна проблема. Оновлення виконуються через ./bitwarden.sh updateself і ./bitwarden.sh update, а під час оновлення застосовуються міграції бази даних. Резервна копія, створена до міграції, не є засобом відкату схеми після неї. Тому створіть резервну копію та зафіксуйте версію, на якій її було створено.

Резервні копії: саме тут найчастіше втрачають сховища

Каталог даних Vaultwarden — це сам сервер. Зберігайте такі дані:

• db.sqlite3
• усі файли rsa_key*, зокрема rsa_key.pem і rsa_key.der
• attachments/
• config.json
• sends/

Не копіюйте db.sqlite3 за допомогою cp, коли контейнер працює. SQLite може саме виконувати запис, тому копія може виявитися пошкодженою базою даних, яка виглядає справною, доки ви не відновите її. Натомість використовуйте API резервного копіювання без зупинки сервісу:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Починаючи з версії 1.32.1, в образі також є вбудована команда /vaultwarden backup. У будь-якому разі знімок залишається на тому самому диску, що й оригінал, доки ви його не перемістите. Тому регулярно передавайте його за межі сервера за допомогою знімків restic у віддалене сховище. Файли rsa_key так само важливі, як і база даних: сервер підписує цим ключем токени сеансів, тому відновлення бази даних поруч із щойно згенерованим ключем призведе до виходу всіх користувачів із системи та порушить запрошення до організацій, які ще оброблялися.

Стандартна версія Bitwarden створює резервні копії більшої кількості даних. Контейнер mssql щоночі записує резервні копії бази даних у ./bwdata/mssql/backups і зберігає їх протягом 30 днів, якщо контейнер працює. Резервну копію можна створити примусово:

docker exec -i bitwarden-mssql /backup-db.sh

Потрібно зберігати каталоги ./bwdata/env (змінні середовища, зокрема паролі бази даних і сертифікатів), ./bwdata/core/attachments, ./bwdata/mssql/data і ./bwdata/core/aspnet-dataprotection. Останній каталог часто забувають. У ньому зберігаються матеріали захисту даних на рівні фреймворку, зокрема токени автентифікації та деякі стовпці бази даних. Тому після відновлення бази даних без цього каталогу захищені ним стовпці буде неможливо прочитати. Bitwarden lite взагалі не створює автоматичних резервних копій. Тому вибір lite означає, що ви маєте самостійно налаштувати розклад створення дампів, так само як для Vaultwarden.

Міграція в будь-якому напрямку

Міграція виконується через клієнти, а не через сервери, оскільки експорт та імпорт є функціями клієнтів. Тому в обох напрямках використовується однакова процедура.

Кожен користувач експортує дані з вебсховища або desktop-застосунку, створює обліковий запис на новому сервері та імпортує дані. Доступні формати: plaintext .json, plaintext .csv, encrypted .json і .zip, який містить JSON та файлові вкладення для окремих сховищ. Картки, ідентифікаційні дані, збережені passkey і SSH-ключі зберігаються лише у форматах JSON, тому міграція через CSV непомітно вилучає їх. Жоден формат експорту не містить елементи з кошика або Sends, а дані, власником яких є організація, не входять до індивідуального експорту.

Сприймайте plaintext-експорт як активний секрет, оскільки це саме він: усе ваше сховище у відкритому вигляді на диску. Експортуйте, імпортуйте та видаляйте його за один сеанс. Ніколи не надсилайте його електронною поштою або через чат.

Під час міграції часто виникає одна проблема. Зашифрований експорт, пов’язаний із вашим обліковим записом, не можна імпортувати в інший обліковий запис, а перенесення на інший сервер за визначенням означає використання іншого облікового запису. Натомість виберіть захищений паролем формат експорту, який можна переносити.

Перенесення з Vaultwarden до стандартного Bitwarden складніше, оскільки структура організації не переноситься в експорті. Створіть організацію на новому сервері, повторно запросіть користувачів, а кожен користувач імпортує власне сховище. Заплануйте для цього вікно технічного обслуговування, а не виявляйте цю проблему в день міграції.

Що слід запускати?

Запускайте Vaultwarden, якщо ви користуєтеся ним одноосібно, для сім’ї або в домашній лабораторії на VPS із 1 GB або 2 GB оперативної пам’яті. Організації, Emergency Access і Send доступні безкоштовно, у режимі простою сервіс споживає приблизно стільки пам’яті, як одна вкладка браузера, а резервна копія складається з файла SQLite і невеликого каталогу. Саме тому Vaultwarden домінує у сфері self-hosted керування паролями.

Запускайте власний сервер Bitwarden, якщо від нього професійно залежать інші люди: компанії потрібен контракт на підтримку, вимоги відповідності прямо визначають постачальника або вам потрібні enterprise-функції, за які ви вже платите. Для стандартного розгортання виділіть 4 GB оперативної пам’яті. Файл ліцензії та installation ID слід вважати частиною розгортання, а не формальністю.

Bitwarden lite посідає проміжне й не дуже зручне місце. Це код постачальника зі значно меншими вимогами до ресурсів, що справді привабливо, але Bitwarden документує його для особистого використання та домашніх лабораторій, і він не має автоматичного резервного копіювання. Ви отримуєте операційне навантаження Vaultwarden, але не отримуєте безкоштовний набір функцій Vaultwarden. Обирайте Bitwarden lite, якщо код постачальника для вас важливіший за функції і ви готові самостійно обслуговувати базу даних.

Якщо ви ще вирішуєте, що саме розмістити на цьому сервері, ширший список варіантів self-hosting допоможе порівняти цей вибір з іншими сервісами, які претендують на ту саму оперативну пам’ять.

FAQ

Чи достатньо безпечний Vaultwarden для повноцінного менеджера паролів?

Для особистого та сімейного використання — так, за певних умов. Клієнти шифрують сховище до того, як воно потрапляє на сервер, тому Vaultwarden ніколи не бачить ваш master password або дані у відкритому вигляді. Безпеку сервера перевіряли зовнішні фахівці: BSI залучила партнерів mgm security для тестування в період із February до May 2024, а ERNW повідомила про обхід автентифікації, який виправили у 1.32.5. Підтримуйте версію в актуальному стані, вимкніть сторінку адміністратора або захистіть її за допомогою хешованого Argon2 ADMIN_TOKEN і використовуйте сервіс лише через HTTPS. Компанії, які потребують підтримки постачальника або аудиторської документації, мають використовувати власний сервер Bitwarden.

Скільки RAM потрібно Vaultwarden порівняно із self-hosted Bitwarden?

Під час вимірювань неактивних інсталяцій за допомогою docker stats --no-stream Vaultwarden із SQLite використовував приблизно 58 MB в одному контейнері, тоді як стандартне розгортання Bitwarden — близько 2,400 MB у 12 контейнерах. Більшу частину цього обсягу займала база даних MSSQL. У документації Bitwarden зазначено 2 GB як мінімальний обсяг і 4 GB як рекомендований для стандартного стека, а для Bitwarden lite — 200 MB. Vaultwarden працює на VPS із 1 GB RAM і має достатньо вільної пам’яті.

Чи потрібна мені ліцензія Bitwarden для self-hosted розгортання?

Для безкоштовного особистого сховища — ні. Використання сервера безкоштовне. Файл ліцензії потрібен для розблокування преміум-функцій особистого сховища та будь-якого платного тарифу для організацій, зокрема Families, Teams і Enterprise. Завантажте його з cloud web vault і передайте до свого екземпляра. Ліцензії для організацій видаються для installation ID, збереженого у ./bwdata/env/global.override.env. Vaultwarden не потребує ліцензії та самостійно вмикає функції організацій.

Чи можна пізніше перейти з Vaultwarden на Bitwarden або виконати зворотний перехід?

Так, в обох напрямках, за допомогою клієнтів. Кожен користувач експортує своє сховище з web vault або desktop app, а після створення облікового запису на новому сервері імпортує його туди. Експорт .zip містить вкладення для особистих сховищ, а формати JSON містять картки, ідентифікаційні дані, passkeys і SSH keys. Елементи з кошика та Sends не входять до жодного формату експорту. Елементи, власником яких є організація, власник має експортувати окремо. Тому на новому сервері потрібно повторно створити організацію та запросити користувачів.