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

MAATRIX

Официальная документация Strapi называет минимум в 2 ГБ RAM и как будто закрывает вопрос — но это цифра для того, чтобы CMS вообще запустилась, а не для того, чтобы она держала реальный проект с десятком content-type, загрузкой файлов и сборкой админки на каждый деплой. На практике память у Strapi «утекает» в трёх разных местах одновременно, и если считать только по факту работающего API-сервера, легко наткнуться на падение процесса ровно в тот момент, когда кто-то запускает npm run build или заливает партию изображений. Разберём, из чего складывается память Strapi и как не промахнуться с тарифом.

Из чего состоит память Strapi

Strapi — это не один процесс с фиксированным аппетитом, а связка из нескольких компонентов, и каждый стоит считать отдельно.

Ядро — сам Node.js-процесс Strapi: HTTP-сервер (Koa под капотом), Content-Type Builder, движок прав доступа, плагины. Это классический V8-процесс с heap, у которого есть настраиваемый лимит --max-old-space-size; в состоянии покоя на пустом проекте с несколькими content-type он держит порядка 200-400 МБ, но это именно состояние покоя, а не пиковая нагрузка.

Второй бюджет — база данных. Strapi по умолчанию в новых проектах предлагает SQLite для быстрого старта, но для продакшена практически всегда используют PostgreSQL — отдельный процесс со своим потреблением RAM, полностью независимым от Node.js. Он не «делится» памятью с приложением, и его нужно закладывать сверху, а не вычитать из общего бюджета сервера.

Третий, и самый недооценённый — сборка админки. Панель управления Strapi — это React-приложение, которое собирается через Webpack (или Vite в новых версиях) командой npm run build. Сама сборка — краткосрочный, но очень прожорливый по памяти процесс: на проекте среднего размера она легко забирает 1-1.5 ГБ в пике на несколько минут, и именно это чаще всего роняет маленький VPS, а не штатная работа API.

Четвёртый — обработка загружаемых файлов. Если используется встроенный provider для изображений с генерацией responsive-размеров через sharp, каждая крупная загрузка даёт кратковременный всплеск потребления памяти пропорционально размеру исходного файла.

Dev-режим и production: разница в разы

В режиме разработки (strapi develop) Node.js держит в памяти файловый watcher, несжатый билд админки в dev-режиме, hot-reload — процесс на пустом проекте легко занимает 500 МБ – 1 ГБ уже в состоянии покоя. Это нормально для локальной разработки, но не показатель того, сколько нужно в проде.

В production (strapi start после strapi build) процесс работает с уже собранной статикой админки, без watcher — потребление ниже и стабильнее в состоянии покоя, но добавляется нагрузка от реальных запросов: сериализация ответов API с глубокими populate-связями (когда в одном запросе тянутся связанные content-type в несколько уровней), одновременные загрузки файлов, параллельные соединения к базе.

Важный нюанс с самим процессом сборки: если вы пересобираете админку прямо на продакшен-сервере при каждом деплое (git pull && npm run build && pm2 restart), пиковое потребление в момент сборки может быть выше, чем всё остальное приложение вместе взятое. Это стоит либо закладывать в тариф сервера с запасом, либо переносить сборку в CI и заливать на сервер уже готовый build-каталог.

Сколько RAM нужно по сценариям использования

Ниже — ориентировочные пороги, а не гарантия: реальное потребление зависит от числа content-type, глубины связей между ними, объёма загружаемых медиафайлов и от того, собираете ли вы админку на самом сервере.

Для честного знакомства «поднять и посмотреть» 2 ГБ хватает впритык — это дев-режим на пустой базе. Как только вы подключаете PostgreSQL, начинаете реально наполнять контент и заливать медиа — комфортнее переходить на 4 ГБ. Если пересобираете админку на самом сервере при каждом деплое, 4 ГБ станут узким местом в момент сборки даже при спокойной работе API — берите 6-8 ГБ или выносите сборку в CI.

PostgreSQL: отдельный бюджет, не общий котёл

PostgreSQL под Strapi — обычная реляционная база без экзотики, но её аппетит растёт с числом связей между content-type (каждая связь many-to-many в Strapi — это дополнительная join-таблица) и объёмом контента. Базовые ориентиры для настройки на одном сервере со Strapi:

shared_buffers = 25% от RAM, выделенной под PostgreSQL
effective_cache_size = 50-75% от той же доли
work_mem = 4-16 МБ
maintenance_work_mem = 256 МБ достаточно для типового проекта

Не отдавайте PostgreSQL теоретическую четверть от всей RAM сервера — считайте от фактически выделенной ему доли, оставляя место под Node.js-процесс Strapi и, если он есть, кратковременный всплеск от сборки админки. Пошаговую установку и базовую конфигурацию смотрите в статье про установку PostgreSQL на VPS, а точную настройку shared_buffers и work_mem под конкретный объём RAM — в разборе тюнинга PostgreSQL. Если PostgreSQL на вашем сервере регулярно падает по нехватке памяти — отдельно разбирали причины и решения в статье PostgreSQL: out of memory.

Если начинали проект на SQLite для быстрого старта — учтите, что SQLite почти не расходует отдельную память (файл на диске, без своего процесса), но и не годится для нагрузки с несколькими одновременными писателями: миграция на PostgreSQL при росте проекта — это не только вопрос надёжности, но и появление нового отдельного бюджета RAM, который раньше не требовался. Саму установку Strapi с нуля — Node.js, PostgreSQL, PM2 и Nginx как reverse proxy — разбирали пошагово в статье про установку Strapi на VPS.

PM2 и лимит памяти процесса

Strapi в продакшене почти всегда запускают через PM2 — менеджер процессов, который следит за живостью Node.js-приложения и перезапускает его при падении. PM2 умеет ограничивать процесс по памяти и автоматически перезапускать его при превышении лимита:

pm2 start npm --name strapi -- run start
pm2 restart strapi --max-memory-restart 1500M

Флаг --max-memory-restart — это не «увеличить память», а страховка от утечки: если процесс Strapi по какой-то причине начинает бесконтрольно расти (например, из-за плагина, который держит ссылки на объекты и не даёт их собрать garbage collector'у), PM2 перезапустит его раньше, чем он утащит с собой весь сервер через OOM killer ядра. Ставьте лимит с запасом от типового потребления в покое, но заметно ниже общей RAM сервера — иначе перезапуск всё равно произойдёт слишком поздно, вместе с падением соседних процессов.

Для самой сборки на сервере при деплое лимит PM2 не поможет — процесс npm run build в момент сборки часто вообще не находится под управлением PM2 (это отдельная разовая команда), и здесь важнее общий объём RAM сервера, а не настройки менеджера процессов.

Как понять, что памяти не хватает

Нехватка RAM у Strapi редко выглядит как явная ошибка сразу — чаще это растущее время ответа API, зависающая сборка или тихий перезапуск процесса:

# Общая картина по памяти и свопу
free -h

# Кто ест память прямо сейчас
htop

# Убивал ли ядро процессы по нехватке памяти
dmesg | grep -i "out of memory"
journalctl -k | grep -i "killed process"

# Статус и потребление процесса под PM2
pm2 list
pm2 monit

# Внутри Node.js-процесса: heap usage
node -e "console.log(process.memoryUsage())"

Если в логах при сборке видите FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory — это V8 упёрся в лимит heap именно во время npm run build, и здесь есть два разных решения в зависимости от причины: если на сервере физически хватает RAM, можно временно поднять лимит через NODE_OPTIONS="--max-old-space-size=2048" npm run build; если же свободной памяти реально нет — поднимать лимит heap бессмысленно, нужен либо сервер с большим объёмом RAM, либо перенос сборки в CI. Регулярные записи Killed process ... (node) в dmesg — прямой сигнал, что ядро останавливает процесс Strapi по нехватке физической памяти, а не ошибка в коде приложения.

Быстрые меры без апгрейда сервера: перенести сборку админки в CI и деплоить готовый build-каталог, ограничить глубину populate в тяжёлых API-запросах (глубокие вложенные связи резко увеличивают объём сериализуемых данных в памяти), проверить work_mem PostgreSQL, если сложные выборки конкурируют за память с Node.js-процессом. Своп стоит держать как аварийную подушку на случай кратковременного пика при сборке, но не как постоянную опору — под свопом сама сборка может растянуться с минут до десятков минут. Подробнее о том, когда своп реально нужен и как его настроить — в статье когда нужен swap-файл.

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