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

MAATRIX

CryptPad — редкий случай, когда сервер физически не может прочитать то, что вы редактируете: шифрование происходит в браузере, а на диск и в память сервера попадают только зашифрованные блоки. Это меняет и расчёт ресурсов: в отличие от OnlyOffice или Collabora, здесь нет тяжёлого процесса конвертации документов, зато есть своя специфика с realtime-синхронизацией и обязательными двумя доменами. Разберём, сколько памяти закладывать под разные сценарии и что реально её ест.

Архитектура: почему CryptPad легче, чем кажется

CryptPad — это Node.js-приложение (пакет cryptpad, официальный образ cryptpad/cryptpad), которое отдаёт статику, держит WebSocket-соединения для совместного редактирования и складывает зашифрованные данные в файловую систему. Никакого LibreOffice, никакого headless-браузера для рендера — конвертация форматов (например, экспорт в .docx) выполняется тоже на клиенте либо простыми библиотеками, без тяжёлого процесса-конвертера. Именно поэтому CryptPad ощутимо экономнее по памяти, чем OnlyOffice или Collabora Online: у тех отдельный конвертер на базе LibreOffice может сам по себе съедать 300–500 МБ на процесс, у CryptPad такого узла просто нет.

Память сервера в основном уходит на три вещи:

• Node.js-процесс — сам API/realtime-сервер, база heap ~150–300 МБ на старте плюс рост с числом активных WebSocket-соединений и открытых документов.
• Realtime-синхронизация (ChainPad) — пока документ открыт хотя бы одним пользователем, сервер держит в памяти его историю операций до контрольной точки (checkpoint). Чем больше одновременно открытых, активно редактируемых документов — тем больше растёт heap.
• Файловый и дисковый кеш ОС — сами зашифрованные блоки (blob/, block/) лежат на диске, но Linux активно кеширует их в свободной RAM при чтении, что снижает задержки, но не является обязательным расходом.

Важный нюанс архитектуры, который влияет на инфраструктуру: CryptPad требует два разных домена (или поддомена) — основной и «песочницу» (sandbox domain). Контент документов рендерится в iframe с отдельного origin, чтобы вредоносный HTML внутри документа не мог получить доступ к куки и localStorage основного сайта. На потреблении RAM это не сказывается, но на выбор reverse-proxy и SSL-сертификатов — напрямую: вам нужны сертификаты сразу на оба домена.

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

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

Ключевой фактор роста — не число пользователей в базе, а число одновременно открытых для редактирования документов и объём истории правок в каждом до ближайшего checkpoint. CryptPad периодически «схлопывает» историю операций в контрольные точки и выгружает старую историю из памяти на диск, но пока документ открыт активно — часть его состояния держится в heap. Долгие правки без переоткрытия вкладки (например, документ открыт сутками в фоновой вкладке у нескольких человек) — типичный сценарий, где память растёт заметнее, чем ожидалось из таблицы.

Для команды до 10 человек с обычной офисной нагрузкой (документы, таблицы, kanban-доски Wekan-подобного типа, которые есть в CryptPad из коробки) 4 ГБ RAM на VPS — комфортный старт с запасом, а не впритык.

Установка через Docker Compose

Официальный и самый предсказуемый способ развернуть CryptPad — Docker-образ cryptpad/cryptpad. Каталоги с данными (blob, block, data, datastore) нужно вынести в volume, чтобы шифротекст пользователей пережил пересоздание контейнера.

services:
  cryptpad:
    image: cryptpad/cryptpad:latest
    restart: unless-stopped
    environment:
      - CPAD_MAIN_DOMAIN=https://pad.example.com
      - CPAD_SANDBOX_DOMAIN=https://pad-sandbox.example.com
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - ./cryptpad-data:/cryptpad/data
      - ./cryptpad-blob:/cryptpad/blob
      - ./cryptpad-block:/cryptpad/block
      - ./cryptpad-customize:/cryptpad/customize
      - ./cryptpad-config:/cryptpad/config
    deploy:
      resources:
        limits:
          memory: 3g
        reservations:
          memory: 1g

Лимит memory: 3g в секции deploy.resources.limits работает только при развёртывании через docker stack deploy (Swarm-режим); при обычном docker compose up для жёсткого лимита нужен параметр mem_limit на уровне сервиса или ограничение через systemd/cgroups на хосте. Фактическое действующее ограничение проще всего проверить командой docker stats cryptpad.

Домены CPAD_MAIN_DOMAIN и CPAD_SANDBOX_DOMAIN CryptPad подставит в config.js при первом старте; при ручном редактировании конфига ищите поля httpUnsafeOrigin (основной домен) и httpSafeOrigin (домен-песочница). Оба должны резолвиться на один сервер, но обслуживаться reverse-proxy как разные origin — например, pad.example.com и pad-sandbox.example.com с отдельными записями A и отдельными SSL-сертификатами.

Node.js: где реальный потолок памяти

По умолчанию V8 (движок Node.js) ограничивает старый heap величиной, зависящей от доступной RAM хоста, но исторически по умолчанию это около 2 ГБ на 64-битных системах для процессов, где Node сам не увидел больше. Если у вас VPS с 2 ГБ RAM целиком под контейнер и внутри него ещё живут другие процессы (nginx, cron, мониторинг), Node может упереться в лимит раньше, чем физическая память закончится, и упасть с JavaScript heap out of memory.

Поднять лимит вручную можно через переменную окружения при старте контейнера:

environment:
  - NODE_OPTIONS=--max-old-space-size=3072

Здесь 3072 — мегабайты под heap; выставляйте с запасом ниже общего лимита контейнера (например, при mem_limit: 4g разумно ограничить heap 3072 МБ, оставив 1 ГБ на буферы и файловый кеш процесса). Маленькое значение ускорит паузы сборщика мусора под нагрузкой, слишком большое без физического объёма приведёт к OOM-килу со стороны ядра — это резче, чем контролируемое исключение самого Node.js.

Если сервер отвечает медленнее, а docker stats не показывает упора в память — чаще всего дело не в RAM, а в одном CPU-ядре: Node.js однопоточный для основной логики, и на 1 vCPU realtime-синхронизация нескольких активных документов начинает конкурировать за процессорное время раньше, чем закончится память.

Хранилище данных: диск считается отдельно от RAM

Зашифрованные блоки документов, файлов и истории правок CryptPad хранит на диске в каталогах blob/ (загруженные файлы — изображения, вложения) и block/ (ключи шифрования аккаунтов), а метаданные каналов синхронизации — в data/. Это не оперативная память, но при планировании VPS диск часто оказывается узким местом раньше RAM, особенно если пользователи активно заливают файлы через встроенное файловое хранилище CryptPad Drive.

Полезные команды для контроля:

# Общий размер данных CryptPad
du -sh cryptpad-data cryptpad-blob cryptpad-block

# Найти самые тяжёлые вложения
du -ah cryptpad-blob | sort -rh | head -20

# Запустить встроенную очистку неиспользуемых данных
# (выполняется внутри контейнера, команда из штатного набора cryptpad)
docker exec -it cryptpad node scripts/evict-inactive.js

Квоты на пользователя настраиваются в config.js (поле defaultStorageLimit) — без ограничения один активный пользователь с привычкой заливать видео в CryptPad Drive может неожиданно съесть десятки гигабайт SSD. Закладывайте под это отдельный бюджет диска, а не «про запас» RAM — эти два ресурса в CryptPad почти не пересекаются.

Реверс-прокси, SSL и нагрузка на два домена

Поскольку CryptPad обязателен к двум origin, типичная схема — один VPS, один Node-процесс на порту 3000, а nginx перед ним слушает оба домена и проксирует оба на один и тот же upstream. Дополнительной RAM это почти не требует (сам nginx лёгкий), но раздельные сертификаты Let's Encrypt нужно продлевать для обоих доменов — при автоматизации через certbot добавьте оба в один -d список или заведите два отдельных сертификата.

server {
    listen 443 ssl http2;
    server_name pad.example.com pad-sandbox.example.com;

    ssl_certificate     /etc/letsencrypt/live/pad.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pad.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

Заголовки Upgrade/Connection "upgrade" обязательны — без них WebSocket-соединения для realtime-редактирования не устанавливаются, и CryptPad деградирует до неработающей синхронизации, хотя статика при этом отдаётся нормально (частая причина «страница открылась, а документ не редактируется совместно»). Если планируете держать CryptPad рядом с другими инструментами совместной работы на одном сервере, сверьтесь по памяти со статьями сколько RAM нужно для OnlyOffice и сколько RAM нужно для Nextcloud — расход RAM у сервисов не пересекается, поэтому цифры просто суммируются.

Мониторинг, swap и что делать при нехватке памяти

Держать под рукой базовый мониторинг стоит с первого дня, а не после первого падения под нагрузкой:

# Живая картина по контейнеру
docker stats cryptpad

# Что именно ест память внутри процесса Node.js
docker exec cryptpad node -e "console.log(process.memoryUsage())"

# Общая память хоста
free -h

Если бюджет ограничен и RAM впритык, файл подкачки снимает риск мгновенного OOM-килла при кратковременном всплеске (например, сотрудники разом открыли квартальный отчёт после отпуска), но не заменяет расчёт объёма — swap на VPS с SSD спасает от падения, а не ускоряет работу под устойчивой нагрузкой. Как настроить — в статьях swap-файл: когда нужен и как настроить и правильный размер swap для VPS. Для CryptPad 1–2 ГБ swap как страховка достаточно даже на инстансах с 4–8 ГБ RAM — это буфер на пиковые секунды, а не постоянно используемый ресурс.

Если после нескольких недель эксплуатации docker stats стабильно показывает потребление близко к лимиту даже в спокойные часы — это сигнал не тюнить NODE_OPTIONS до бесконечности, а перейти на тариф с большим объёмом RAM: рост потребления в стабильном режиме почти всегда означает, что реальное число активных документов и пользователей превысило тот сценарий, под который считался сервер изначально.

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