Сколько RAM нужно для Joplin Server

MAATRIX

Joplin — удобный блокнот с шифрованием и синхронизацией между устройствами, но по умолчанию он тянет заметки либо в закрытое облако Joplin Cloud, либо в сторонние Dropbox/OneDrive/WebDAV, которые не всегда хочется использовать для личных записей. Joplin Server решает это: вы поднимаете свой сервер синхронизации и держите заметки под полным контролем. Вопрос в другом — сколько памяти реально нужно, чтобы сервер не падал под нагрузкой, но и не переплачивать за неиспользуемые гигабайты.

Что вообще такое Joplin Server и из чего он состоит

Joplin Server — это не файловое хранилище в привычном смысле, а полноценное серверное приложение на Node.js, которое реализует протокол синхронизации Joplin: принимает зашифрованные (если включено E2E) блоки данных от клиентов, хранит их в базе и раздаёт обратно при синхронизации с других устройств. У него есть веб-интерфейс администратора, система пользователей и общих блокнотов (Joplin Server поддерживает шаринг заметок между аккаунтами — это его главное отличие от простого WebDAV).

Технически это связка из трёх частей:

• API-сервер на Node.js — сама логика синхронизации, аутентификации, обработки шаринга;
• База данных — PostgreSQL (рекомендуется для продакшена) или SQLite (годится только для одного пользователя и теста);
• Хранилище вложений — либо прямо в БД, либо на файловой системе, либо в S3-совместимом объектном хранилище.

Именно эта архитектура определяет потребление памяти: сам Node.js-процесс легковесный, а вот база данных и раздача файлов — это то, где память может «поплыть» при росте числа заметок и одновременных синхронизаций.

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

Прежде чем говорить о конкретных цифрах, важно понимать компоненты нагрузки:

1. Node.js runtime — сам процесс joplin-server в состоянии покоя занимает немного, обычно в пределах 100-200 МБ резидентной памяти. Это база, которая есть всегда, даже без единого пользователя.
2. PostgreSQL — если вы используете отдельный контейнер с Postgres (а это рекомендованная конфигурация), у него своё потребление: shared_buffers, кэш соединений, буферы под запросы. Даже пустая база с настройками по умолчанию держит 50-150 МБ, и это растёт с объёмом данных и числом одновременных подключений.
3. Обработка синхронизации — когда клиент синхронизируется, сервер читает/пишет дельты изменений заметок. Одна заметка — это немного, но у активного пользователя с историей ревизий и вложениями (фото, PDF, скриншоты) объём данных за один цикл синхронизации может быть заметным, и Node.js держит это в памяти на время обработки запроса.
4. Одновременные подключения — если несколько пользователей или устройств синхронизируются параллельно (например, семья или небольшая команда), каждое соединение — это отдельный контекст обработки, который тоже требует памяти, хоть и кратковременно.
5. Reverse-proxy (Caddy/Nginx) — если вы правильно выносите TLS-терминацию на прокси перед Joplin Server, добавьте ещё 20-50 МБ на сам прокси.

Важный нюанс: Joplin Server не индексирует и не парсит содержимое заметок на сервере — вся дешифровка и рендеринг происходят на клиенте. Сервер работает, по сути, как «слепое» хранилище блобов с метаданными, поэтому его нагрузка гораздо ближе к файловому серверу, чем к полноценной CMS с поиском и обработкой контента.

Сколько RAM нужно на практике: ориентировочные сценарии

Ниже — не измеренные бенчмарки, а инженерная оценка на основе архитектуры приложения и типичного поведения Node.js + PostgreSQL под похожей нагрузкой. У вас цифры могут отличаться в зависимости от объёма вложений и настроек PostgreSQL, но порядок величин будет примерно такой.

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

Для команды свыше 20 человек стоит закладывать не только память под сам Joplin Server, но и отдельно думать про диск — вложения растут быстрее, чем текст заметок, и именно диск, а не RAM, обычно становится узким местом первым.

PostgreSQL vs SQLite: что выбрать и как это влияет на память

Официальная документация Joplin прямо рекомендует PostgreSQL для любого сценария, кроме сугубо личного тестового использования. Причина не только в производительности, но и в надёжности при параллельном доступе — SQLite блокирует базу на запись, и при нескольких одновременных синхронизациях это превращается в очереди и таймауты.

С точки зрения памяти разница такая:

• SQLite встроен в процесс Node.js, отдельного потребления почти не создаёт, но и не масштабируется — при росте базы кэш файловой системы под ней растёт бесконтрольно.
• PostgreSQL в отдельном контейнере — это предсказуемое, управляемое потребление. Вы сами задаёте shared_buffers (обычно 25% от выделенной Postgres памяти) и work_mem, и можете держать нагрузку под контролем.

Пример базовой конфигурации Postgres под Joplin Server в docker-compose.yml:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: joplin
      POSTGRES_PASSWORD: change_me
      POSTGRES_DB: joplin
    volumes:
      - joplin_db:/var/lib/postgresql/data
    command: >
      postgres -c shared_buffers=128MB -c work_mem=8MB
               -c max_connections=50

  server:
    image: joplin/server:latest
    restart: unless-stopped
    ports:
      - "22300:22300"
    environment:
      APP_PORT: 22300
      APP_BASE_URL: https://notes.example.com
      DB_CLIENT: pg
      POSTGRES_PASSWORD: change_me
      POSTGRES_DATABASE: joplin
      POSTGRES_USER: joplin
      POSTGRES_HOST: db
      POSTGRES_PORT: 5432
      MAILER_ENABLED: 0
    depends_on:
      - db

volumes:
  joplin_db:

На VPS с 2 ГБ RAM такая связка (Postgres с shared_buffers=128MB + Node.js-процесс) оставляет достаточно запаса под ОС и разовые пики. Урезать shared_buffers ниже 64 МБ не стоит — это скажется на скорости запросов при росте базы.

Если вы уже разворачивали похожие связки на VPS, логика настройки памяти для Postgres в целом такая же, как в общей статье про настройку PostgreSQL на VPS — параметры shared_buffers и max_connections работают одинаково независимо от того, какое приложение стоит поверх базы.

Хранение вложений: где узкое место на самом деле

Вложения (фотографии, сканы, PDF) — самая частая причина, почему RAM «внезапно» перестаёт хватать. Joplin Server поддерживает три варианта хранения:

• Database — вложения лежат прямо в PostgreSQL как BLOB. Просто в настройке, но с ростом объёма вложений раздувает базу и увеличивает нагрузку на Postgres при каждом чтении/записи файла — а значит, косвенно давит и на память, выделенную под кэш базы.
• Filesystem — вложения пишутся на диск сервера отдельно от базы. Это снимает нагрузку с Postgres, но требует, чтобы у вас был персистентный volume и понятная стратегия бэкапа файлов отдельно от дампа БД.
• Object Storage (S3-совместимое) — вложения уезжают во внешнее хранилище (например, MinIO или облачный S3). Это лучший вариант для команд с большим объёмом файлов: сервер Joplin остаётся лёгким, а тяжёлые бинарные данные не участвуют в его памяти вообще.

Если вы рассчитываете на десятки пользователей с активным шарингом фото и документов, режим Database для вложений — не лучший выбор именно из-за влияния на память Postgres. Переключение на Filesystem делается через переменную окружения:

    environment:
      STORAGE_DRIVER: "Type=Filesystem; Path=/app/data"

и монтирование отдельного volume под /app/data.

Reverse-proxy, TLS и итоговая раскладка сервера

Joplin Server сам по себе не умеет TLS — сертификаты нужно терминировать на reverse-proxy перед ним. Стандартная и надёжная связка — Caddy с автоматическим Let's Encrypt, минимальный конфиг:

notes.example.com {
    reverse_proxy localhost:22300
}

Если вы уже настраивали автоматический SSL для других сервисов, шаги для Joplin Server будут ровно такими же, как в статье про установку Caddy с авто-SSL на VPS — меняется только порт и домен в блоке reverse_proxy.

Итоговая раскладка памяти на типичном сервере с 2 ГБ RAM для группы из 5-10 пользователей выглядит так:

Такая раскладка укладывается в 2 ГБ с комфортным запасом. Для команды 20+ человек или большого объёма вложений в БД имеет смысл сразу брать 4 ГБ — это дешевле, чем потом разбираться с OOM-килером посреди рабочего дня, когда несколько человек одновременно синхронизируют большие блокноты.

Бэкапы и обслуживание: о чём часто забывают

Отдельно стоит сказать про операционную сторону, потому что именно она чаще всего подводит self-hosted решения:

• Дамп PostgreSQL нужно снимать регулярно — pg_dump в связке с cron или отдельным контейнером-планировщиком. Если используете Filesystem для вложений, бэкапить нужно и volume с файлами, и дамп базы — раздельно, но синхронизированно по времени.
• Обновления Joplin Server выходят вместе с обновлениями клиента — стоит проверять changelog перед апдейтом, потому что схема базы может мигрировать автоматически при первом старте новой версии, и откат назад без бэкапа будет затруднён.
• Мониторинг диска важнее мониторинга RAM в долгосрочной перспективе — вложения растут постоянно, а память при правильной настройке shared_buffers остаётся стабильной.

Для регулярных бэкапов базы удобно использовать любой инструмент с поддержкой cron-расписаний и ротации — подход из статьи о резервном копировании на VPS через Restic применим и здесь, если вы решите бэкапить не только дамп Postgres, но и файлы вложений в единой стратегии.

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