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

MAATRIX

Если вы пересылаете пароли, конфиги или логи через Telegram или почту, а потом гадаете, кто ещё мог это увидеть, — PrivateBin решает именно эту проблему: заметка шифруется прямо в браузере отправителя, а сервер хранит только нечитаемый набор байт, не имея ключа расшифровки. Это принципиально другая модель, чем у обычного pastebin, и вопрос «сколько RAM закладывать» здесь решается легче, чем для большинства self-hosted сервисов — PrivateBin один из самых лёгких PHP-проектов, которые вообще можно поставить на VPS. Разберём, откуда берётся расход памяти и какой тариф реально нужен.

Что за нагрузку создаёт PrivateBin

PrivateBin — это PHP-приложение без фреймворка в привычном смысле: нет Symfony, Laravel или похожего слоя абстракций, как, например, у Wallabag. Код построен на минимальном наборе классов, роутинг простой, шаблонизация — через нативные PHP-шаблоны без Twig или Blade. Это напрямую отражается на памяти: PHP-FPM воркер PrivateBin в простое занимает заметно меньше, чем воркер под тяжёлый фреймворк.

Ключевая особенность архитектуры — вся криптография происходит на стороне клиента, в браузере, через WebCrypto API (AES-256 в режиме GCM). Сервер физически не выполняет шифрование или расшифровку: он принимает уже зашифрованный blob через POST-запрос и сохраняет его как есть, а при чтении отдаёт тот же blob обратно. Ключ расшифровки живёт только во фрагменте URL (после #) и никогда не попадает на сервер — браузер не отправляет фрагмент URL в HTTP-запросе по спецификации. Из этого следует практический вывод: PrivateBin не грузит CPU и RAM сервера криптографическими операциями вообще, в отличие от сервисов, где шифрование делает бэкенд.

Реальная нагрузка на сервер сводится к трём вещам: приём и запись зашифрованного blob (обычно от пары КБ до нескольких МБ текста, при включённых вложениях — файлы до настроенного лимита), отдача статики (HTML/JS/CSS фронтенда) и опциональная функция «discussion» — зашифрованные комментарии к заметке, которые работают по той же модели нулевого знания.

Из чего складывается расход памяти

Разложим по компонентам то, что реально ест RAM на сервере с PrivateBin:

• PHP-FPM воркеры — каждый активный воркер PrivateBin держит примерно 15-30 МБ, это заметно меньше, чем у Symfony-based приложений (там 40-80 МБ на воркер). Пул из 3-5 воркеров под небольшую нагрузку — это 75-150 МБ.
• Веб-сервер — nginx перед PHP-FPM берёт около 5-15 МБ базово плюс 1-3 МБ на воркер-процесс. Apache с mod_php вместо nginx+FPM обычно ест больше из-за модели «процесс на запрос», поэтому связка nginx + PHP-FPM предпочтительнее.
• Хранилище данных — по умолчанию PrivateBin пишет заметки в файлы в data/ (формат Filesystem), и это не создаёт отдельного процесса вообще: расход памяти на хранилище практически нулевой, только дисковые операции.
• База данных (опционально) — если вместо файлового хранилища выбран backend Database через PDO (MySQL/MariaDB, PostgreSQL или SQLite), отдельный демон СУБД (кроме SQLite) добавляет 100-300 МБ постоянного расхода в простое, независимо от объёма данных.
• Garbage collector — встроенная очистка истёкших заметок запускается на каждый запрос с некоторой вероятностью (настройка gcprobability) либо через отдельный cron-вызов bin/cron.php; это разовая операция без постоянного потребления памяти.
• ОС и системные службы — минимальный Ubuntu/Debian без графики занимает 100-200 МБ на ядро, systemd, cron, sshd.

Итог: даже с запасом на пиковые запросы PrivateBin на файловом хранилище — один из самых экономных по памяти self-hosted сервисов, которые есть в PHP-экосистеме.

Сколько RAM закладывать по сценариям

Для личного использования (делитесь заметками сами с собой или парой коллег, до нескольких десятков заметок в день) минимально рабочий вариант — VPS с 512 МБ RAM: Debian/Ubuntu minimal (~100-150 МБ), nginx + PHP-FPM с пулом на 2-3 воркера (~60-100 МБ), файловое хранилище без отдельной БД. Запаса хватает даже с учётом всплесков при загрузке вложений в разумных пределах.

Цифры ниже — практический ориентир: у вас может отличаться в зависимости от версии PHP, конфигурации PHP-FPM (pm.max_children), включённых вложений и их лимита размера — считайте это отправной точкой, а не гарантией.

Главный параметр, который двигает требования вверх, — не число заметок, а размер и частота вложений: если пользователи регулярно прикладывают файлы близко к максимальному лимиту, растёт не столько RAM, сколько дисковое место и пиковая нагрузка PHP-FPM во время загрузки. Если PrivateBin ставится «для себя» на уже существующий VPS с другими сервисами, он практически не заметен в общем бюджете памяти сервера.

Filesystem vs БД: что выбрать под хранилище

PrivateBin поддерживает несколько backend'ов для хранения заметок, задаётся в cfg/conf.php в секции [model]:

Filesystem (по умолчанию) — заметки сохраняются как отдельные файлы в директории data/. Плюсы: ноль накладных расходов по памяти, простой бэкап (rsync директории), не требует настройки СУБД. Минусы: при очень большом количестве заметок (десятки и сотни тысяч) файловая система с плоской структурой каталогов может деградировать по производительности листинга — но для типичных объёмов self-hosted инстанса это не проблема.

Database (PDO) — MySQL/MariaDB, PostgreSQL или SQLite через единый PDO-слой. Имеет смысл, если вы уже держите СУБД на сервере под другие проекты и хотите централизовать бэкапы, либо если планируете реплицировать/шардировать хранилище заметок между несколькими инстансами PrivateBin за балансировщиком.

S3 / Google Cloud Storage — для сценария, где PrivateBin разворачивается в нескольких экземплярах за балансировщиком нагрузки и нужно общее хранилище между инстансами. Для одиночного VPS это избыточно и добавляет сетевую задержку на каждую операцию без выгоды.

Практический вывод: если не планируете горизонтальное масштабирование, файловое хранилище — правильный выбор по умолчанию, оно и есть основная причина, почему PrivateBin такой лёгкий по памяти на фоне PHP-сервисов с обязательной СУБД.

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

Официальный образ privatebin/nginx-fpm-alpine включает nginx и PHP-FPM в одном контейнере на Alpine — минимальная база уже сама по себе экономит десятки МБ по сравнению с Debian-образами. Вариант с файловым хранилищем:

services:
  privatebin:
    image: privatebin/nginx-fpm-alpine:latest
    container_name: privatebin
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./data:/srv/data
      - ./conf.php:/srv/cfg/conf.php:ro
    deploy:
      resources:
        limits:
          memory: 128M
        reservations:
          memory: 32M

Лимит в 128 МБ — с запасом даже для нескольких одновременных загрузок с вложениями; в реальности контейнер на файловом хранилище редко выходит за 40-60 МБ в простое. Если добавляете PostgreSQL как backend:

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: privatebin
      POSTGRES_USER: privatebin
      POSTGRES_PASSWORD: change_me
    volumes:
      - ./pg-data:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          memory: 256M

Перед контейнером обязательно ставится reverse-proxy с HTTPS — PrivateBin работает только по HTTPS в проде (WebCrypto API в большинстве браузеров недоступен на незащищённом origin, кроме localhost), и это не опционально, а требование самой модели безопасности сервиса. Общая схема связки nginx как reverse-proxy разобрана в статье про настройку Nginx как reverse-proxy на VPS, а получение сертификата — в материале про Let's Encrypt SSL на VPS. Общие принципы mem_limit и reservations в Docker Compose разобраны в статье про лимиты CPU и памяти в Docker.

Настройка лимитов, garbage collector и защита от abuse

В cfg/conf.php есть несколько параметров, которые напрямую влияют на пиковую нагрузку сервера, а не на постоянный расход RAM:

[main]
sizelimit = 10485760  ; максимальный размер заметки+вложения в байтах (10 МБ)

[expire_options]
5min = 300
1hour = 3600
1day = 86400
1week = 604800
never = 0

[traffic]
limit = 10  ; секунд между запросами с одного IP

sizelimit — это главный рычаг: чем больше разрешённый размер вложения, тем выше пиковое потребление памяти PHP-FPM воркера на время обработки запроса (весь blob временно проходит через память процесса). Для личного использования 10 МБ более чем достаточно; для сервиса, где люди делятся логами и дампами конфигов, разумно оставить лимит в диапазоне 5-20 МБ, а не открывать его на сотни МБ — иначе один воркер на время загрузки крупного файла может занять сотни МБ RAM, и при нескольких параллельных загрузках это складывается.

Секция [traffic] — встроенная защита от злоупотреблений: ограничивает частоту создания новых заметок с одного IP. Это не влияет на память напрямую, но снижает риск ситуации, когда бот заваливает сервис запросами и параллельно раздувает число активных PHP-FPM воркеров до предела пула.

Garbage collector, который удаляет истёкшие заметки, по умолчанию срабатывает вероятностно на каждый запрос (gcprobability = 1 из 100 в conf.php). На сервере с низкой посещаемостью это может означать, что истёкшие заметки будут годами занимать место, если их никто не открывает. Надёжнее вынести очистку в cron:

# /etc/cron.d/privatebin-gc
0 3 * * * www-data php /var/www/privatebin/bin/cron.php

Это не экономит RAM в моменте, но держит дисковое пространство и число файлов в data/ под контролем, что косвенно важно для производительности файлового хранилища на больших объёмах.

Проверить реальное потребление перед апгрейдом тарифа:

free -h
docker stats --no-stream          # если через Docker
systemctl status php8.3-fpm       # если без Docker
du -sh /var/www/privatebin/data   # объём накопленных заметок

Если видите OOM-killer в dmesg в моменты загрузки вложений — либо снижен sizelimit слишком незначительно относительно доступной памяти, либо pm.max_children в пуле PHP-FPM выставлен выше, чем сервер реально способен обслужить параллельно; про диагностику нехватки памяти в целом — в статье что делать при нехватке RAM.

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