Psono рассчитан на команду, Vaultwarden — на семью: разница видна сразу

MAATRIX

«Какой self-hosted менеджер паролей лучше» — вопрос без честного ответа, потому что Psono и Vaultwarden решают разные задачи разными средствами. Vaultwarden — чужая реализация протокола Bitwarden в одном Rust-бинарнике: минимум ресурсов, официальные клиенты, отличный выбор для себя или семьи. Psono — самостоятельный продукт на Python/Django, спроектированный сразу под организацию: группы с раздельными правами, аудит-лог, LDAP и SSO, деление на Community и Enterprise. Ниже — сравнение архитектуры, прав доступа и денег без маркетинга, чтобы решить, для какого размера команды тяжеловесность Psono себя окупает, а где Vaultwarden справится лучше и дешевле.

Два разных проекта, а не два варианта одного

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

Psono с этой экосистемой не пересекается вообще. Это независимый протокол и независимые клиенты: сервер на Python/Django с REST API, веб-клиент на React (несколько лет назад переехал с AngularJS), отдельная веб-консоль для администраторов, мобильные приложения для iOS и Android, расширения для Chrome и Firefox. Официальное приложение Bitwarden к серверу Psono не подключить в принципе — не потому что кто-то что-то не доделал, а потому что это разные протоколы с разной криптографией на клиенте.

Лицензии тоже разные, и разница не только формальная. Vaultwarden распространяется под AGPLv3 — сильный копилефт, любая модификация, которую вы раздаёте (в том числе как сервис), обязана публиковать исходники. Psono Community Edition и его клиенты — под Apache 2.0: разрешительная лицензия без обязательства раскрывать доработки, что важнее для компаний, которые хотят форкнуть код под себя и не публиковать изменения.

Ресурсы и установка: один контейнер против стека сервисов

Vaultwarden — один процесс и файл SQLite, docker stats в простое показывает порядка 20–60 МиБ на пользователя произвольного числа: пятеро и полсотни человек по памяти почти неотличимы. Установка — три строки Caddy или короткий Nginx-конфиг поверх одного контейнера, пошагово — в статье как установить и настроить Vaultwarden на VPS.

Psono изначально проектировался как разносимый стек, и это видно уже в официальных рекомендациях по железу для разных масштабов:

Даже нижняя строка — это уже минимум два сервиса (СУБД и приложение) вместо одного бинарника, и официальная документация прямо советует держать базу отдельно от приложения ради бэкапов и последующего масштабирования. СУБД — PostgreSQL от версии 14 или MySQL; SQLite, на котором держится Vaultwarden, Psono не поддерживает вообще.

Установка идёт через объединённый образ psono/psono-combo, который несёт в себе сервер, веб-клиент и админ-консоль, но не базу:

# генерация ключей сервера — хранить ADMIN_RECOVERY_PRIVATE_KEY офлайн, не класть в settings.yaml
docker run --rm -ti psono/psono-combo:latest python3 ./psono/generateserverkeys.py

Дальше — settings.yaml с блоком базы и набором секретов, которые нельзя пропустить:

SECRET_KEY: "..."             # 32+ символов
ACTIVATION_LINK_SECRET: "..." # 32+ символов
DB_SECRET: "..."              # 32+ символов
WEB_CLIENT_URL: "https://psono.example.com"
HOST_URL: "https://psono.example.com/server"
DATABASES:
  default:
    ENGINE: 'django.db.backends.postgresql_psycopg2'
    NAME: 'psono'
    USER: 'psono'
    PASSWORD: 'your-password'
    HOST: '203.0.113.10'   # не localhost внутри контейнера
    PORT: '5432'

Миграция базы и первый запуск:

docker run --rm -v /opt/docker/psono/settings.yaml:/root/.psono_server/settings.yaml \
  -ti psono/psono-combo:latest python3 ./psono/manage.py migrate

docker run --name psono-combo --sysctl net.core.somaxconn=65535 \
  -v /opt/docker/psono/settings.yaml:/root/.psono_server/settings.yaml \
  -v /opt/docker/psono-client/config.json:/usr/share/nginx/html/config.json \
  -d --restart=unless-stopped -p 10200:80 psono/psono-combo:latest

Плюс регулярный manage.py cleartoken через cron — документация советует вешать его по расписанию. Итог честный: у Vaultwarden — один compose.yaml и десять минут; у Psono — генерация ключей, отдельная база, файл секретов и обслуживающая задача. Больше шагов — больше мест ошибиться, но стек с самого начала рассчитан вырасти без переделки архитектуры.

Права доступа: где заканчивается Vaultwarden и начинается Psono

Здесь не всё так однозначно в пользу Psono, как кажется по маркетингу. У Vaultwarden уже в бесплатной версии есть организации, коллекции и группы — это не премиальная функция, а часть открытого протокола Bitwarden, доступная всем. Разрыв не в наличии структуры, а в её глубине и в том, что вокруг неё построено.

Модель Psono устроена так: у каждой записи или папки, которой поделились, есть три уровня прав — Read (читать содержимое), Write (менять содержимое) и Grant (менять сами права доступа, включая свои, и передавать шаринг дальше). Отдельно от этого — права на саму группу: Group Admin управляет составом группы и правами участников, Share Admin может привязывать к группе новые записи и папки. На практике это даёт трёхслойную структуру: у отдела двенадцать рядовых участников с правом Read/Write на конкретные шары, у двоих есть Share Admin, чтобы заводить новые секреты для отдела, и только у одного — Group Admin, чтобы управлять составом. Документация прямо советует шарить не отдельные записи, а папки целиком — новое содержимое внутри такой папки автоматически становится видно всем, у кого есть доступ, без ручного подтверждения каждой записи.

У Vaultwarden ролевая модель организации плоская: владелец, администратор, менеджер, обычный участник — права привязаны к роли в организации в целом, а не выдаются гранулярно по каждой записи с отдельным правом «переустанавливать чужие права». Для команды из десяти человек с одной общей папкой разницы почти не видно. Для отдела с подотделами, где нужно явно развести «кто видит», «кто редактирует» и «кто управляет доступом остальных» — разница ощутима уже на второй-третьей группе.

Второй практический разрыв — источник правды о составе групп. У Psono в Enterprise-редакции группы можно синхронизировать напрямую из LDAP/Active Directory, SAML или OIDC: сотрудник уволился в HR-системе — через группу-маппинг он лишается доступа без ручной правки в панели. У Vaultwarden поддержка SSO по OIDC есть, но заявлена как экспериментальная, а SCIM и автоматический directory sync отсутствуют — офбординг там остаётся ручной операцией.

Community и Enterprise: что бесплатно, а что за деньги

У Vaultwarden биллинга нет вообще — раз нет платных тарифов, премиальные функции официального Bitwarden (TOTP, вложения, экстренный доступ, сами организации) открыты всем без исключения. Плата за это — то, что аудит-лога, зрелого SSO и compliance-политик там не появится в принципе: это не вопрос тарифа, а вопрос архитектуры стороннего проекта, который не претендует на корпоративный сегмент.

У Psono деление на Community и Enterprise — осознанное решение с самого начала:

Compliance-политики в Enterprise стоит расшифровать отдельно — это не абстрактная строчка, а конкретные переключатели с префиксом COMPLIANCE_: принудительная 2FA для всех, минимальная длина и сложность мастер-пароля, запрет экспорта хранилища целиком или только чужих шаров, запрет создавать группы в обход администратора, ограничение по IP, автоочистка буфера обмена через заданный интервал, отключение офлайн-режима. Всё это применяется точечно — на конкретного пользователя или группу, а не на весь сервер разом.

По деньгам официальная страница Psono даёт конкретный ориентир: Enterprise-функции бесплатны для команд до 10 человек включительно, а для коллективов от 25 пользователей цена стартует от 2,5 евро за пользователя в месяц. Для диапазона между 10 и 25 пользователями точных публичных цифр нет — это стоит уточнять у Psono напрямую, а не подставлять экстраполяцией. Сравнивать эту цифру напрямую с подпиской Bitwarden Teams не совсем корректно: там вы платите за облако целиком, здесь — только за лицензию на функции, сервер вы всё равно держите и обслуживаете сами. Экономику self-hosted менеджера паролей против облачной подписки на конкретных цифрах для офиса разбирали в статье про расчёт своего менеджера паролей вместо подписки на офис в 40 человек — логика применима и здесь, просто с другим поставщиком лицензии.

Для какого размера и структуры команды это имеет смысл

• Один человек, семья, команда до 5–7 человек. Vaultwarden выигрывает без вариантов: один контейнер, минимум ресурсов, официальные клиенты без переучивания. Даже бесплатный лимит Psono Enterprise до 10 пользователей не аргумент в его пользу — содержать отдельную СУБД и генерировать серверные ключи ради пяти человек не окупается временем администратора.
• Растущая команда 10–50 человек с несколькими отделами. Здесь начинает работать модель Group Admin / Share Admin из Psono: у разработки, финансов и поддержки — разные группы с разными администраторами, подрядчика на проект добавляют в одну группу с ограниченным Read/Write и убирают одним действием по завершении. Про саму боль пересылки паролей в чате и то, что решает нормальный менеджер паролей на уровне отдельной команды, — в статье менеджер паролей для команды: хватит слать в чат.
• Компания с Active Directory/Entra ID как источником правды. Если увольнение сотрудника в HR-системе должно мгновенно резать доступ к паролям, а не через отдельную ручную операцию, — это прямое показание к Psono Enterprise с LDAP или SAML group-mapping. У Vaultwarden такого пути нет, SSO там экспериментальный.
• Требования по аудиту и политикам. Если кто-то извне (клиент, партнёр, внутренняя служба безопасности) должен видеть, кто и когда открывал конкретный секрет, или организация обязана принудительно включить 2FA всем и запретить экспорт хранилища — это функции, которых у Vaultwarden нет ни в каком виде, а не «есть, но хуже».
• От сотни пользователей и выше, с требованием отказоустойчивости. Здесь разговор о Vaultwarden прекращается сам собой — он не проектировался под HA и кластеризацию. Таблица сайзинга Psono для среднего и крупного масштаба выше — это уже конкретный план по железу, а не гипотеза.

Миграция и совместимость: можно ли перейти без потерь

Вендор-лока на уровне данных нет ни у того, ни у другого — оба используют открытые форматы экспорта. Практически переезд с Vaultwarden на Psono выглядит так: в клиенте Bitwarden/Vaultwarden делаете экспорт хранилища (Инструменты → Экспорт, формат JSON или CSV), в Psono — импорт через меню пользователя → Other → Import, которое принимает CSV, JSON и XML от целого ряда других менеджеров, включая формат Bitwarden.

Ловушка в другом: структура не переносится автоматически. Коллекции и организации Bitwarden — не то же самое, что группы и папки Psono, поэтому после импорта записи придётся вручную разложить по нужным группам и заново выставить права Read/Write/Grant — это ручная работа, а не галочка при импорте. Вложения в экспорте Bitwarden/Vaultwarden — только метаданные, сами файлы нужно выгружать отдельно через CLI до того, как старый сервер выключат.

Обратное направление, Psono → Bitwarden/Vaultwarden, на практике более шероховатое — в сообществе периодически всплывают жалобы на то, что часть записей или структура папок переносится не полностью. Если решение о переезде не окончательное, разумно сначала прогнать миграцию на копии данных, а не в проде: несовпадение моделей прав — это то место, где красивый экспорт превращается в день ручной раскладки.

Частые вопросы