Сколько RAM нужно для Passbolt

MAATRIX

Команда переросла общий файл с паролями в таблице или разрозненные Bitwarden-аккаунты и решает поднять свой Passbolt — с ролями, группами и общими паролями под контролем. Первый практический вопрос при выборе сервера — сколько оперативной памяти закладывать, чтобы не переплатить за тариф с запасом, но и не словить OOM-килл на проде в первую неделю. Разберём, из чего складывается потребление RAM у Passbolt, дадим ориентировочные цифры по размеру команды и покажем, как настроить и измерить нагрузку на своём сервере.

Из чего состоит Passbolt и почему это влияет на RAM

Passbolt Community Edition — это веб-приложение на CakePHP (PHP), которое отдаётся через nginx + PHP-FPM, и база данных MySQL/MariaDB. Официальный образ passbolt/passbolt в режиме ce разворачивает оба слоя — веб-сервер с приложением и, отдельным контейнером, базу.

Важная особенность архитектуры, которая напрямую влияет на требования к памяти: основная криптография (шифрование и расшифровка паролей) выполняется на клиенте, в браузерном расширении через OpenPGP.js. Сервер в основном хранит и раздаёт уже зашифрованные блобы, сверяет права доступа и отправляет уведомления по почте. Это значит, что Passbolt не нагружает сервер тяжёлыми криптографическими операциями так, как это делают, например, некоторые VPN-протоколы или сервисы транскодирования — основная нагрузка на RAM здесь типична для обычного PHP-приложения с базой: PHP-FPM воркеры, обработка HTTP-запросов, буферы MariaDB.

Дополнительно у Passbolt есть фоновые задачи (очистка сессий, истёкших приглашений, отправка email через очередь) — они запускаются по cron внутри контейнера приложения и заметного веса не добавляют. В Pro-версии появляются LDAP/SSO-плагины и дополнительные джобы — они увеличивают потребление, но некритично для малых и средних команд.

Минимальный старт: сколько RAM для команды до 10–15 человек

Для небольшой команды (менее 15 активных пользователей, работа в основном в рабочие часы) реалистичный минимум — 2 ГБ RAM на весь стек (приложение + база на одном сервере). Формально Passbolt может подняться и на 1 ГБ, но на таком объёме почти не остаётся запаса под всплески: несколько человек одновременно открыли расширение после обеда — и PHP-FPM с MariaDB конкурируют за последние сотни мегабайт, начинаются задержки ответа и в худшем случае OOM-килл процесса.

Ориентировочное распределение для этого сценария:

Это ориентир, а не измеренный бенчмарк — точные цифры зависят от версии Passbolt, настроек PHP-FPM (pm.max_children) и от того, крутится ли на этом же сервере что-то ещё. Для 1 vCPU + 2 ГБ RAM команда до 10–15 человек обычно работает стабильно; для запаса на рост берите 4 ГБ сразу — разница в цене тарифа обычно небольшая, а мигрировать базу потом дороже по времени, чем сэкономленные деньги.

Как растёт потребление с числом пользователей и активностью

Здесь неочевидный момент: потребление RAM у Passbolt масштабируется не столько от общего числа пользователей в базе, сколько от числа одновременных запросов к API. Сама база данных остаётся компактной даже при тысячах записей — Passbolt хранит зашифрованные секреты и метаданные (кто с кем поделился, какие теги, какие группы), это текстовые и небольшие бинарные поля, а не файлы. База на 500 пользователей и десятки тысяч паролей вполне помещается в несколько сотен мегабайт на диске.

А вот PHP-FPM воркеры съедают память пропорционально числу параллельных запросов: браузерное расширение периодически опрашивает сервер (проверка новых записей, синхронизация), и если у вас 50 человек одновременно за компьютерами в 10 утра понедельника, всплеск параллельных подключений будет заметно выше, чем ночью. Каждый PHP-FPM процесс под Passbolt занимает по опыту эксплуатации подобных CakePHP-приложений порядка 30–60 МБ resident memory — это тоже ориентир, реальная цифра зависит от opcache и версии PHP, замерьте её на своём сервере (как — в разделе ниже) прежде чем закладывать в план.

Практические ориентиры по размеру команды:

При переходе за 200 пользователей и активном использовании групп/шаринга разумно вынести MariaDB на отдельный инстанс — это не столько вопрос RAM, сколько изоляции нагрузки: тяжёлый бэкап или ALTER TABLE на базе не должны роняли отклик приложения для всей компании.

Docker Compose с лимитами памяти

Официальный способ развернуть Passbolt — docker-compose с двумя сервисами. Ниже — рабочий каркас с явными лимитами памяти, чтобы контейнеры не расползались на весь сервер и вы сразу видели, если что-то упирается в потолок:

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    mem_limit: 1g
    mem_reservation: 512m

  passbolt:
    image: passbolt/passbolt:latest-ce
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: https://passbolt.example.com
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: ${DB_PASSWORD}
      DATASOURCES_DEFAULT_DATABASE: passbolt
      EMAIL_TRANSPORT_DEFAULT_HOST: smtp.example.com
      EMAIL_TRANSPORT_DEFAULT_PORT: 587
      EMAIL_TRANSPORT_DEFAULT_USERNAME: ${SMTP_USER}
      EMAIL_TRANSPORT_DEFAULT_PASSWORD: ${SMTP_PASSWORD}
      EMAIL_TRANSPORT_DEFAULT_TLS: "true"
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt
    ports:
      - "443:443"
    mem_limit: 1g
    mem_reservation: 400m

volumes:
  db_data:
  gpg_data:
  jwt_data:

Для сервера на 2 ГБ этот набор лимитов (1 ГБ + 1 ГБ) оставляет мало запаса системе — на практике лучше выставить mem_limit чуть ниже физического максимума (например, 700m + 700m на 2-гигабайтном сервере), чтобы у ядра и докер-демона тоже осталось пространство. Про общий подход к лимитам подробнее — в статье про лимиты CPU и памяти в Docker.

Тюнинг PHP-FPM и MariaDB под доступный объём памяти

Если контейнер приложения зажат лимитом, а не тюнингом внутри, PHP-FPM может расплодить больше воркеров, чем помещается в память, и получить OOM. В официальном образе Passbolt конфиг PHP-FPM обычно лежит по пути /etc/php/8.x/fpm/pool.d/www.conf внутри контейнера — переопределите его через bind mount, если нужно жёстко ограничить число процессов:

[www]
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4

Грубая формула для pm.max_children: (память, выделенная контейнеру, минус ~150 МБ на nginx и master-процесс) делённая на средний размер одного PHP-FPM воркера, который вы замерили на своём сервере. Закладывайте round down — лучше меньше воркеров, чем неожиданный OOM в пиковый час.

Для MariaDB главный рычаг — innodb_buffer_pool_size. Это основной кэш данных и индексов в памяти, и он должен занимать заметную долю выделенного контейнеру объёма, но не весь:

[mysqld]
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
max_connections = 50

Для базы Passbolt (она компактная) 256–512 МБ буфера обычно достаточно даже на команду в несколько сотен человек — расти в первую очередь имеет смысл max_connections, если PHP-FPM держит много параллельных соединений к базе, а не сам объём данных.

Как измерить реальное потребление на своём сервере

Прежде чем выбирать план "на глаз", поднимите Passbolt на любом доступном сервере и посмотрите на реальные цифры под вашей нагрузкой — это надёжнее любых ориентиров из статьи:

# Живое потребление по каждому контейнеру
docker stats passbolt_passbolt_1 passbolt_db_1

# Общая картина по хосту
free -h

# Что ест память внутри контейнера приложения
docker exec -it passbolt_passbolt_1 ps aux --sort=-rss | head -20

docker stats без флагов обновляется в реальном времени и показывает MEM USAGE / LIMIT — если контейнер регулярно упирается в лимит, это сигнал поднять mem_limit или разобраться, что именно растёт (обычно PHP-FPM воркеры при наплыве запросов). Смотрите не разовый снимок, а поведение в течение недели с реальной командой — пиковая нагрузка в понедельник утром обычно отличается от среднего показателя в разы.

Если сервер уже применялся под другие задачи и вы разворачиваете Passbolt рядом, свежий пошаговый чек-лист установки docker и compose под прод — в статье про установку Docker Compose на Ubuntu 24.04.

Что делать, если памяти не хватает

Симптомы нехватки памяти обычно однозначные: контейнер passbolt периодически перезапускается (docker ps показывает Restarting), в логах MariaDB — Out of memory, а в браузере пользователи видят зависшие запросы или 502 от nginx. Порядок действий:

1. Проверьте dmesg | grep -i "killed process" — если ядро действительно убивало процесс по OOM, это подтверждение диагноза, а не совпадение.
2. Временно добавьте swap как страховку (fallocate -l 2G /swapfile && mkswap /swapfile && swapon /swapfile) — это не решение, а буфер, чтобы сервис не падал, пока вы разбираетесь. Для MariaDB на постоянной основе swap — плохая идея: свопинг горячих страниц буферного пула резко просаживает отклик базы.
3. Снизьте pm.max_children и innodb_buffer_pool_size пропорционально факту, а не ощущениям — по цифрам из docker stats.
4. Если после тюнинга всё равно упираетесь в потолок регулярно, а не в редких пиках — это не баг конфигурации, а сигнал роста: переходите на тариф с большим объёмом RAM или выносите базу на отдельный сервер.

Если Passbolt для вас пока избыточен по требованиям или команда небольшая, посмотрите на более лёгкую альтернативу — сравнение разобрано в статье Vaultwarden против Bitwarden, а установка Vaultwarden — в отдельном гайде. Для управления секретами приложений (а не паролями людей) чаще уместнее HashiCorp Vault — это другая по назначению система, но вопрос иногда путают.

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