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

MAATRIX

Команда переросла Google Docs и разрозненные заметки, вы поставили Outline — открытую вики с Markdown-редактором и быстрым поиском, которую часто берут как self-hosted замену Notion. Осталось решить банальный вопрос: сколько сервера под неё покупать. Outline тянет за собой PostgreSQL, Redis и хранилище для вложений, поэтому «поставлю на 1 ГБ и посмотрю» обычно заканчивается OOM-киллером в момент, когда кто-то заливает скриншот. Ниже — из чего складывается память Outline и какие цифры закладывать под разный размер команды.

Из чего состоит Outline и куда уходит память

Outline — это не один процесс, а связка из нескольких сервисов, и почти каждый жалуется на память по-своему:

• Сам Outline (Node.js) — рендерит редактор, отдаёт API, держит WebSocket-соединения для совместного редактирования. В простое ест немного, но каждый одновременно открытый документ с несколькими редакторами держит в памяти состояние Y.js-документа (это движок, на котором построено совместное редактирование) — чем больше людей одновременно правят разные страницы, тем выше базовый расход.
• PostgreSQL — основное хранилище: документы, ревизии, права доступа, структура коллекций. У Postgres память растёт управляемо через shared_buffers, но у него всегда есть нижняя планка, ниже которой начинаются деградации на запросах поиска.
• Redis — очередь фоновых задач (экспорт, уведомления, индексация), pub/sub для realtime-обновлений между вкладками и инстансами. Сам по себе лёгкий, но плохо переживает нехватку памяти — начинает терять данные очереди вместо ошибки.
• Хранилище вложений — Outline умеет писать файлы локально на диск (с версии, где убрали обязательный S3) или в S3-совместимое хранилище. Если поднимаете MinIO рядом на том же сервере — добавьте ещё один процесс со своим аппетитом.
• Reverse proxy (Caddy/nginx/Traefik) — обычно копейки, но забывать про него в расчётах не стоит.

Итог: даже «пустой» Outline — это минимум 3-4 процесса, конкурирующих за одну и ту же память, и ни один из них не резиновый.

Минимальный сервер: пилот и небольшая команда до 10 человек

Если вы разворачиваете Outline посмотреть, приживётся ли он, или команда — это 5-10 человек, которые заглядывают в вики пару раз в день, хватает скромной конфигурации:

На таком сервере комфортно работают несколько сотен документов и десяток одновременных сессий. Узкое место здесь не Outline сам по себе, а совместный доступ к памяти между тремя процессами на одной машине — если Postgres и Redis не ограничить, они будут расти до тех пор, пока не столкнутся друг с другом на OOM. Ориентир: закладывайте своп 1-2 ГБ как страховку на этапе пилота, но не как постоянное решение — на свопе Postgres резко теряет отзывчивость на поиске.

Продакшен для команды 10-50 человек

Это самый частый случай — рабочая вики отдела или небольшой компании, куда заходят регулярно, редактируют документы параллельно, ищут по контенту несколько раз в час.

На 4 ГБ Outline держит запас на всплески: экспорт документов в PDF, массовую переиндексацию после импорта из Confluence или Notion, несколько десятков одновременных редакторов. Именно на этом этапе стоит вынести PostgreSQL или хранилище вложений на отдельный сервер, если бюджет позволяет — тогда падение одного компонента не роняет вики целиком, и вам проще масштабировать Postgres независимо. Здесь пригодится пошаговая установка PostgreSQL на VPS — Outline требует версию не ниже 12, и правильно выставленный shared_buffers сразу снимает часть нагрузки на диск.

Крупная вики: 100+ человек, большая база документов

Когда вики становится основным источником знаний в компании — тысячи документов, активная работа с вложениями, десятки одновременных редакторов в разных документах — расход памяти растёт нелинейно, в первую очередь за счёт Postgres и активных WebSocket-соединений.

На этом масштабе имеет смысл разнести сервисы по разным серверам: приложение Outline отдельно, PostgreSQL отдельно (с возможностью апгрейда только его памяти без переустановки остального), хранилище вложений — отдельно. Это не столько экономия RAM, сколько защита от ситуации, когда один прожорливый процесс топит остальные. Если вы уже сравнивали, какую СУБД тянуть для больших нагрузок, пригодится материал про тюнинг PostgreSQL под конкретный сервер — там разбор, как считать shared_buffers и effective_cache_size от реального объёма RAM, а не по шаблону.

Совместное редактирование и поиск: скрытые потребители памяти

Два места в Outline, где память расходуется не так линейно, как хочется думать:

1. Realtime-редактирование. Когда несколько человек одновременно правят один документ, Outline держит в памяти его состояние для синхронизации изменений между клиентами (движок на базе Y.js). Пока документов, редактируемых параллельно, немного — это заметно не сказывается. Но если у вас практика «все правим один регламент в переговорке» на десятках документов одновременно (например, во время ежеквартального ревью процессов) — кратковременный пик памяти может быть заметно выше обычного дневного расхода. Закладывайте запас, а не считайте по среднему.
2. Полнотекстовый поиск. Outline ищет по документам через встроенный полнотекстовый поиск PostgreSQL (tsvector), без отдельного Elasticsearch или Meilisearch — это упрощает архитектуру, но означает, что вся нагрузка поиска ложится на Postgres. На небольшой базе документов это незаметно, но при тысячах страниц с частыми запросами стоит следить за shared_buffers и индексами, а не считать, что поиск «бесплатный» по памяти.

Отдельно стоит правило, которое легко забыть: RAM нужна не только под пиковую нагрузку, но и под фоновые задачи — импорт архива из Confluence/Notion, массовый экспорт в PDF, переиндексацию после смены структуры коллекций. Эти операции запускаются через очередь Redis и обрабатываются в фоне, но кратковременно поднимают потребление памяти заметно выше обычного — если сервер и так работает впритык, такие операции — частая причина внезапного падения по OOM.

docker-compose с лимитами памяти — рабочий пример

Официальный способ разворачивать Outline — через Docker, и на любом сервере стоит сразу выставлять лимиты на каждый сервис, чтобы один прожорливый процесс не увёл в OOM остальные три:

services:
  outline:
    image: outlinewiki/outline:latest
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    env_file: .env
    mem_limit: 1g
    ports:
      - "3000:3000"

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: outline
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: outline
    volumes:
      - pg_data:/var/lib/postgresql/data
    command: postgres -c shared_buffers=256MB -c effective_cache_size=768MB
    mem_limit: 768m

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --maxmemory 256mb --maxmemory-policy noeviction
    volumes:
      - redis_data:/data
    mem_limit: 320m

volumes:
  pg_data:
  redis_data:

Это конфигурация под команду до 30-40 человек (суммарно чуть больше 2 ГБ лимитов плюс запас под ОС и reverse proxy — с них и стоит начинать расчёт объёма сервера). Обратите внимание на --maxmemory-policy noeviction для Redis — если Outline использует его как очередь задач, а не только как кэш, вытеснение данных по LRU может тихо потерять фоновую задачу вместо явной ошибки. Redis для Outline настраивается отдельным вопросом — если раньше не поднимали его на проде, посмотрите установку и настройку Redis на VPS. А если решите вынести хранилище вложений на MinIO вместо локального диска — пригодится установка MinIO на VPS, там же про лимиты памяти под сам MinIO.

Если после Outline присматриваетесь и к другим self-hosted альтернативам корпоративным SaaS, расчёт памяти по похожей логике — сервис плюс БД плюс очередь — актуален и для Nextcloud, который часто ставят рядом как файловое хранилище для той же команды.

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