Сколько RAM нужно для Standard Notes

MAATRIX

Standard Notes выбирают не за красивый редактор, а за принцип: end-to-end шифрование по умолчанию, открытый исходный код и обещание, что заметки останутся читаемыми через 20 лет, даже если сам сервис исчезнет. Логичное продолжение этой логики — держать сервер синхронизации у себя, а не доверять чужой инфраструктуре ключи от зашифрованных данных (пусть даже сервер их и не видит в открытом виде). Проблема в том, что self-hosted Standard Notes — это не один процесс, а связка из нескольких сервисов, и официальная документация не даёт прямого ответа "берите X гигабайт". Разберём, из чего складывается расход памяти и сколько закладывать под разные сценарии.

Как устроен self-hosted Standard Notes изнутри

Standard Notes построен как набор отдельных Node.js-сервисов, а не монолитное приложение. В самостоятельном хостинге (self-hosted edition проекта) обычно разворачивают:

• API Gateway — точка входа, маршрутизирует запросы клиентов к нужному сервису.
• Auth-сервер — регистрация, вход, управление сессиями и ключами шифрования (сами ключи сервер не видит — шифрование происходит на устройстве пользователя).
• Sync-сервер — принимает и раздаёт зашифрованные "items" (заметки, теги, настройки) между устройствами.
• Files-сервер (опционально) — приём и отдача зашифрованных вложений; в облачной версии это платная функция, в self-hosted — доступна без ограничений, но требует отдельного сервиса и места на диске.
• Websockets-сервер — держит постоянные соединения для мгновенной синхронизации между открытыми клиентами.
• PostgreSQL — основное хранилище зашифрованных данных.
• Redis — кэш, очереди задач и pub/sub между сервисами.

Важный нюанс: сервер никогда не расшифровывает содержимое заметок — шифрование и расшифровка происходят в браузере или приложении пользователя. Это снимает с сервера нагрузку на криптографию, но не снимает нагрузку на инфраструктуру: каждый из перечисленных сервисов — это отдельный Node.js-процесс со своим базовым потреблением памяти, плюс PostgreSQL и Redis со своими резидентными наборами. Именно сумма базовых накладных расходов нескольких процессов, а не объём текста в заметках, определяет минимальный порог RAM.

Сколько RAM нужно по факту: ориентиры

Точных цифр от разработчиков Standard Notes на все сценарии нет — нагрузка зависит от числа пользователей, устройств на каждого и того, включены ли вложения и websocket-синхронизация. Ниже — ориентировочные пороги, собранные из практики эксплуатации связок PostgreSQL + Redis + несколько Node.js-сервисов; на вашей установке цифры могут отличаться, особенно если вложения — это в основном фото и сканы документов, а не текстовые файлы.

Оговорка та же, что и для любой связки из нескольких микросервисов: в состоянии покоя каждый Node.js-процесс редко ест больше 100-150 МБ, PostgreSQL с настройками по умолчанию — около 100-200 МБ, Redis — считаные десятки мегабайт при небольшом объёме данных. На бумаге это укладывается в 700-900 МБ суммарно. Но брать сервер впритык под эту цифру — плохая идея: пики возникают при одновременном входе нескольких устройств после долгого офлайна (полная синхронизация всей базы разом), при массовой загрузке вложений или при перезапуске всех контейнеров сразу, когда PostgreSQL и Redis прогреваются параллельно с остальными сервисами.

Что нагружает память сильнее всего

• PostgreSQL. Каждое активное соединение — это отдельный процесс на стороне БД, и даже при небольшом числе пользователей несколько сервисов (auth, sync, files) держат к нему собственные пулы соединений одновременно. Разрастание базы происходит не столько от текста заметок, сколько от истории версий (revisions) — Standard Notes хранит предыдущие ревизии зашифрованных items, и на активно редактируемой базе это существенно увеличивает объём таблиц.
• Redis. Используется под сессии, очереди уведомлений и pub/sub между сервисами (например, чтобы websocket-сервер узнавал о новых изменениях от sync-сервера). При небольшом числе пользователей это несущественный расход, но на публичном self-host с десятками активных сессий очередь может заметно вырасти.
• Files-сервер. Приём вложения — это, по сути, приём произвольного зашифрованного бинарного потока: сервер не может "заглянуть" внутрь файла и оптимизировать обработку, поэтому крупные вложения (сканы, PDF, фото) дают кратковременные, но заметные пики потребления памяти на приём/отдачу.
• Websocket-соединения. Каждое открытое устройство с включённой мгновенной синхронизацией держит постоянное соединение. Три-пять устройств на личном сервере не создают нагрузки, но на инсталляции с десятками одновременных пользователей это уже надо закладывать отдельной строкой.
• Reverse proxy и TLS. Как и для любого self-hosted сервиса с несколькими эндпоинтами (API, sync, files, websockets часто разносят по поддоменам или путям), nginx или Caddy перед всем этим добавляет ещё 30-60 МБ.

Установка через Docker Compose с лимитами памяти

Практичнее всего разворачивать self-hosted Standard Notes через Docker Compose — так проще видеть потребление каждого сервиса отдельно, а не гадать, что именно раздулось. Ниже — пример для личного использования с явными лимитами памяти на каждый контейнер:

services:
  db:
    image: postgres:15-alpine
    container_name: sn-db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=standardnotes
      - POSTGRES_USER=standardnotes
      - POSTGRES_PASSWORD=change_me
    volumes:
      - ./data/db:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          memory: 512m

  cache:
    image: redis:7-alpine
    container_name: sn-cache
    restart: unless-stopped
    command: redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru
    deploy:
      resources:
        limits:
          memory: 200m

  server:
    image: standardnotes/self-hosted:latest
    container_name: sn-server
    restart: unless-stopped
    depends_on:
      - db
      - cache
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - ./.env
    volumes:
      - ./data/uploads:/opt/standard-notes/uploads
    deploy:
      resources:
        limits:
          memory: 1.5g
        reservations:
          memory: 512m

Порт сервера намеренно привязан к 127.0.0.1 — наружу отдаётся через reverse proxy с TLS. Минимальный конфиг Caddy:

notes.example.com {
    reverse_proxy 127.0.0.1:3000
}

Файл .env в официальном образе содержит десятки переменных (секреты JWT, ключи шифрования на стороне сервера для служебных данных, адреса внутренних сервисов) — их состав меняется между версиями образа, поэтому конкретный список лучше брать из актуального .env.sample в репозитории проекта на момент установки, а не копировать откуда-то целиком. Суммарные лимиты в примере (512m + 200m + 1.5g ≈ 2.2 ГБ) — это защита от аномалий вроде утечки после долгого аптайма, а не рекомендация "и хватит впритык": сам сервер должен иметь запас поверх суммы лимитов на ОС, бэкапы и краткие пики нескольких сервисов одновременно.

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

Перед тем как переезжать на тариф побольше, стоит понять, где именно упирается память — в PostgreSQL, в Redis или в сам Node.js-сервис.

Быстрая проверка по каждому контейнеру:

docker stats sn-db sn-cache sn-server --no-stream

Если резидентная память sn-db стабильно растёт без явного роста числа записей — проверьте, не копится ли история ревизий заметок сверх разумного, и не забыт ли VACUUM на таблицах с частыми обновлениями:

docker exec -it sn-db psql -U standardnotes -c "VACUUM (VERBOSE, ANALYZE);"

Если растёт sn-cache — посмотрите, не превышен ли maxmemory и не пора ли его поднять (Redis с allkeys-lru сам вытесняет старые ключи, но если maxmemory занижен, это может увеличивать число промахов кэша и косвенно нагружать остальные сервисы).

Если память системно не хватает (контейнеры падают по OOM — проверяется в dmesg или docker inspect <container> --format='{{.State.OOMKilled}}'), порядок действий:

1. Добавить 1-2 ГБ swap — спасает от жёсткого падения при разовых пиках синхронизации нескольких устройств, но не решает проблему постоянной нехватки.
2. Проверить, не сам ли deploy.resources.limits.memory стал причиной убийства контейнера — если лимит занижен относительно реальной нагрузки, ослабьте его, прежде чем менять тариф сервера.
3. Перейти на тариф с большим объёмом RAM — если нагрузка объективно выросла (добавились пользователи, включили вложения для всех), это единственное устойчивое решение.

Как выбрать сервер под свой сценарий

Для личного использования без претензий на большой объём вложений хватает младшего VPS на 1-2 ГБ RAM — здесь важнее не запас по памяти, а надёжный SSD-диск: PostgreSQL чувствителен к скорости диска на запись, а каждое сохранение заметки — это отдельная транзакция. Если вы уже смотрели похожие self-hosted альтернативы для заметок вроде Trilium Notes, заметите общий паттерн: небольшие Node.js-сервисы с БД хорошо себя чувствуют на 1-2 ГБ, пока речь не идёт о десятках активных пользователей или тяжёлых вложениях.

Для семьи или небольшой команды с общими вложениями и включённой websocket-синхронизацией закладывайте от 3-4 ГБ RAM и 2 vCPU — резерв нужен не столько под сам Standard Notes в спокойном состоянии, сколько под одновременный вход нескольких устройств после офлайна и под приём крупных файлов. Если вы уже держите на том же сервере другой сервис, ориентированный на приватность — например, CryptPad для совместного редактирования или Passbolt для командных паролей — считайте память для каждого сервиса отдельно и суммируйте: общего запаса "на всё сразу" не существует, а общая идея self-hosted приватных инструментов обычно предполагает именно такой набор из нескольких сервисов на одном сервере.

Локация сервера для Standard Notes важна не с точки зрения задержки (шифрование и синхронизация асинхронны, 100-150 мс разницы почти не ощущаются в интерфейсе), а с точки зрения юрисдикции: часть пользователей self-hosted шифрованных заметок сознательно выбирают локацию сервера отдельно от места проживания или от юрисдикции основного бизнеса — это часть общей логики "данные зашифрованы и физически лежат там, где я решил". Если сомневаетесь, сколько памяти закладывать с запасом на будущее — общие принципы разобраны в статье сколько оперативной памяти закладывать с запасом.

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