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

MAATRIX

В требованиях Coolify стоит «2 ГБ RAM» — цифра честная ровно для того, чтобы панель открылась и показала пустой дашборд. Первая же сборка фронтенда на такой машине заканчивается строкой exit code: 137, а следом иногда ложится и сама панель. Разберём по граммам: сколько держат контейнеры Coolify, сколько просит сборка каждого популярного стека и как посчитать свою цифру вместо «запаса на всякий случай».

Короткий ответ: сколько памяти брать под Coolify

Если нужен ответ без чтения всей статьи — вот он, по сценариям. Цифры для чистого сервера, где кроме Coolify ничего не крутится.

Главное, что стоит унести: память под Coolify — это не одна цифра, а две. Постоянное потребление в простое (панель плюс работающие контейнеры) и пик на время сборки, который живёт три-четыре минуты и легко удваивает нагрузку. Сервер падает не в простое, а на пике — под него и считайте запас.

Про CPU, раз уж считаем железо: сборка — задача процессорная. На 2 vCPU Next.js собирается 4–6 минут, на 4 vCPU — полторы-две.

Куда уходит память: разбор по контейнерам

Coolify четвёртой ветки — управляющий слой над Docker, после установки поднимается пять служебных контейнеров. Кто сколько ест, видно одной командой:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}"

На простаивающем сервере с 8 ГБ вывод такой:

NAME               MEM USAGE / LIMIT      MEM %     CPU %
coolify            512.8MiB / 7.752GiB    6.46%     0.61%
coolify-db         386.4MiB / 7.752GiB    4.87%     0.34%
coolify-realtime   118.2MiB / 7.752GiB    1.49%     0.12%
coolify-proxy      104.6MiB / 7.752GiB    1.32%     0.08%
coolify-redis      48.3MiB / 7.752GiB     0.61%     0.19%

Итого около 1,15 ГБ резидентной памяти — до того, как вы задеплоили хоть что-то своё. Больше всех берёт основной контейнер: это Laravel с очередями и планировщиком, PHP-воркеры держат память постоянно и обратно её не отдают. coolify-db — Postgres со стандартным shared_buffers = 128MB плюс расход на каждое соединение.

К контейнерам прибавьте хост: dockerd с shim-процессами — 120–180 МБ, systemd с журналом, sshd и агент мониторинга — ещё 150–250 МБ. Итого база платформы 1,4 ГБ, и выглядит она так:

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.4Gi       4.9Gi        24Mi       1.5Gi       6.1Gi
Swap:          4.0Gi          0B       4.0Gi

Смотрите на available, а не на free: в buff/cache лежит дисковый кэш, ядро отдаст его приложениям по требованию. Именно available — память, на которую можно рассчитывать при следующей сборке. Включённые метрики сервера (Sentinel) добавят ещё контейнер и 50–100 МБ: штука полезная, но на машине с 2 ГБ от неё лучше отказаться.

Сборка — вот где память кончается

Типичная картина: панель работает неделю, всё зелёное, вы жмёте Deploy — и лог обрывается на шаге npm run build:

#12 [builder 5/5] RUN npm run build
#12 CANCELED
------
failed to solve: process "/bin/sh -c npm run build" did not complete successfully: exit code: 137

137 — это 128 + 9, то есть SIGKILL. Убил процесс не Docker и не Coolify, а ядро; подтверждение даёт dmesg -T | grep -i "killed process":

[Tue Aug 25 03:11:47 2026] Out of memory: Killed process 24193 (node) total-vm:4210332kB,
anon-rss:1683244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:6540kB oom_score_adj:0

Точечная проверка контейнера — docker inspect --format '{{.State.OOMKilled}}' <container_id>. Ответ true закрывает вопрос: это память, и правки Dockerfile тут не помогут. Разбор соседних симптомов — в материале про частые ошибки Coolify.

Сколько просит сборка — зависит от стека. Замеры пиковой резидентной памяти сборочного контейнера на средних проектах:

Отсюда и берётся правило: сервер на 4 ГБ, у которого 1,4 ГБ занято базой, оставляет сборке около 2,5 ГБ доступной памяти. Next.js в них попадает, но впритык, а Angular — уже нет.

Полумера, которая часто спасает, — ограничить кучу Node переменной сборки (Environment Variables, галочка Build variable): NODE_OPTIONS=--max-old-space-size=1536. Честно про минус: памяти это не добавляет, а меняет форму отказа. Вместо убийства процесса ядром вы получите управляемое FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory, и на большом проекте сборка всё равно не закончится. Зато сервер и панель выживут, а не уйдут в swap-шторм.

Сколько добавляет каждое приложение и база

Пик сборки разовый, а рантайм живёт постоянно и определяет, сколько сервисов поместится. Ориентиры на реальных контейнерах:

• Node / Next.js в standalone-режиме — 120–250 МБ на инстанс.
• PHP-FPM, пул на 5 воркеров — 250–400 МБ, каждый воркер держит свой интерпретатор.
• Python + uvicorn, 2 воркера — 150–300 МБ.
• Go-бинарник — 15–60 МБ, лучший сосед на маленьком сервере.
• PostgreSQL 16, до 10 соединений — 180–350 МБ.
• MySQL 8 — 400–500 МБ сразу после старта, даже пустой. При жёстком бюджете берите Postgres.
• Redis без данных — 15–40 МБ, растёт вместе с ключами, если не задан maxmemory.

Две вещи, на которых спотыкаются. Базы из панели стартуют с дефолтным конфигом образа: shared_buffers = 128MB на 4 ГБ — нормально, но десять таких баз рядом — полтора гигабайта впустую. И Redis без maxmemory растёт, пока не упрётся в память хоста, а OOM-killer выберет жертвой не его, а самый крупный процесс — вашу базу или панель.

Практическое правило для планирования: постоянное потребление = 1,4 ГБ (Coolify и хост) + сумма рантаймов ваших сервисов, а свободного оставляйте не меньше, чем пик самой тяжёлой сборки.

Как выжить на 4 ГБ: swap, zram и лимиты

Swap-файл — обязательный минимум, он разобран в статье про установку и настройку Coolify на VPS. Здесь — то, что делают поверх него.

zram вместо (или вместе с) файла подкачки. Сжатый swap в памяти в разы быстрее дискового и хорошо ложится на сборки, где много однотипных данных. Ставим apt install -y zram-tools и правим /etc/default/zramswap:

ALGO=zstd
PERCENT=50
PRIORITY=100

Дальше systemctl restart zramswap. На 4 ГБ это даёт 2 ГБ сжатого пространства с коэффициентом 2,5–3. Приоритет 100 ставит zram выше дискового swap. Плата — CPU на сжатие, а он на сборке и так узкое место.

Подкрутить sysctl в /etc/sysctl.d/99-coolify.conf, применить sysctl --system:

vm.swappiness=10
vm.vfs_cache_pressure=50
vm.overcommit_memory=0

swappiness=10 не запрещает swap, а откладывает его до реальной нужды. А вот популярный совет поставить vm.overcommit_memory=1 для сервера сборок вреден: он разрешает выдавать память, которой нет, и вместо честного отказа вы получите сервер, зависший на минуты.

Лимиты на приложения. В карточке приложения есть Advanced → лимиты ресурсов, под капотом это докеровские --memory и --memory-swap. В своём compose то же самое:

deploy:
  resources:
    limits:
      memory: 512M

Смысл в изоляции: контейнер с утечкой умрёт сам и перезапустится, а не утащит панель. Минус честный — его убьют ровно на лимите, даже если на сервере есть свободная память.

earlyoom, чтобы сервер не вис. Штатный OOM-killer срабатывает слишком поздно: машина успевает уйти в свап и перестать отвечать даже по SSH. Демон из пакета earlyoom бьёт раньше и выборочно — в /etc/default/earlyoom:

EARLYOOM_ARGS="-m 6 -r 3600 --avoid '(^|/)(dockerd|sshd|systemd|coolify)
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Coolify
Сборка — вот где память кончается
Типичная картина: панель работает неделю, всё зелёное, вы жмёте Deploy — и лог обрывается на шаге npm run build:
#12 [builder 5/5] RUN npm run build
#12 CANCELED
------
failed to solve: process "/bin/sh -c npm run build" did not complete successfully: exit code: 137
137 — это 128 + 9, то есть SIGKILL. Убил процесс не Docker и не Coolify, а ядро; подтверждение даёт dmesg -T | grep -i "killed process":
[Tue Aug 25 03:11:47 2026] Out of memory: Killed process 24193 (node) total-vm:4210332kB,
anon-rss:1683244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:6540kB oom_score_adj:0
Точечная проверка контейнера — docker inspect --format '{{.State.OOMKilled}}' <container_id>. Ответ true закрывает вопрос: это память, и правки Dockerfile тут не помогут. Разбор соседних симптомов — в материале про частые ошибки Coolify.
Сколько просит сборка — зависит от стека. Замеры пиковой резидентной памяти сборочного контейнера на средних проектах:
Стек
Пик сборки
Что съедает
Статика на Vite/React
0,7–1,4 ГБ
Rollup держит граф модулей в памяти
Next.js 15, 30–50 маршрутов
1,8–2,6 ГБ
Компиляция + типы + пререндер страниц
Nuxt 3
1,6–2,4 ГБ
Двойная сборка: клиент и сервер
Angular, production build
2,5–4,0 ГБ
Прожорливее всех фронтендов
Laravel + composer + vite
0,9–1,5 ГБ
Пик даёт фронтенд, не PHP
Python / FastAPI
0,25–0,6 ГБ
Обычно просто установка колёс
Go, multi-stage
0,4–0,9 ГБ
Зависит от числа пакетов
Rust, cargo build --release
1,5–3,0 ГБ
LLVM на оптимизациях
Java Spring, Gradle
1,5–2,5 ГБ
JVM демона сборки
Отсюда и берётся правило: сервер на 4 ГБ, у которого 1,4 ГБ занято базой, оставляет сборке около 2,5 ГБ доступной памяти. Next.js в них попадает, но впритык, а Angular — уже нет.
Полумера, которая часто спасает, — ограничить кучу Node переменной сборки (Environment Variables, галочка Build variable): NODE_OPTIONS=--max-old-space-size=1536. Честно про минус: памяти это не добавляет, а меняет форму отказа. Вместо убийства процесса ядром вы получите управляемое FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory, и на большом проекте сборка всё равно не закончится. Зато сервер и панель выживут, а не уйдут в swap-шторм.
Сколько добавляет каждое приложение и база
Пик сборки разовый, а рантайм живёт постоянно и определяет, сколько сервисов поместится. Ориентиры на реальных контейнерах:
Node / Next.js в standalone-режиме — 120–250 МБ на инстанс.
PHP-FPM, пул на 5 воркеров — 250–400 МБ, каждый воркер держит свой интерпретатор.
Python + uvicorn, 2 воркера — 150–300 МБ.
Go-бинарник — 15–60 МБ, лучший сосед на маленьком сервере.
PostgreSQL 16, до 10 соединений — 180–350 МБ.
MySQL 8 — 400–500 МБ сразу после старта, даже пустой. При жёстком бюджете берите Postgres.
Redis без данных — 15–40 МБ, растёт вместе с ключами, если не задан maxmemory.
Две вещи, на которых спотыкаются. Базы из панели стартуют с дефолтным конфигом образа: shared_buffers = 128MB на 4 ГБ — нормально, но десять таких баз рядом — полтора гигабайта впустую. И Redis без maxmemory растёт, пока не упрётся в память хоста, а OOM-killer выберет жертвой не его, а самый крупный процесс — вашу базу или панель.
Практическое правило для планирования: постоянное потребление = 1,4 ГБ (Coolify и хост) + сумма рантаймов ваших сервисов, а свободного оставляйте не меньше, чем пик самой тяжёлой сборки.
Как выжить на 4 ГБ: swap, zram и лимиты
Swap-файл — обязательный минимум, он разобран в статье про установку и настройку Coolify на VPS. Здесь — то, что делают поверх него.
zram вместо (или вместе с) файла подкачки. Сжатый swap в памяти в разы быстрее дискового и хорошо ложится на сборки, где много однотипных данных. Ставим apt install -y zram-tools и правим /etc/default/zramswap:
ALGO=zstd
PERCENT=50
PRIORITY=100
Дальше systemctl restart zramswap. На 4 ГБ это даёт 2 ГБ сжатого пространства с коэффициентом 2,5–3. Приоритет 100 ставит zram выше дискового swap. Плата — CPU на сжатие, а он на сборке и так узкое место.
Подкрутить sysctl в /etc/sysctl.d/99-coolify.conf, применить sysctl --system:
vm.swappiness=10
vm.vfs_cache_pressure=50
vm.overcommit_memory=0
swappiness=10 не запрещает swap, а откладывает его до реальной нужды. А вот популярный совет поставить vm.overcommit_memory=1 для сервера сборок вреден: он разрешает выдавать память, которой нет, и вместо честного отказа вы получите сервер, зависший на минуты.
Лимиты на приложения. В карточке приложения есть Advanced → лимиты ресурсов, под капотом это докеровские --memory и --memory-swap. В своём compose то же самое:
deploy:
  resources:
    limits:
      memory: 512M
Смысл в изоляции: контейнер с утечкой умрёт сам и перезапустится, а не утащит панель. Минус честный — его убьют ровно на лимите, даже если на сервере есть свободная память.
earlyoom, чтобы сервер не вис. Штатный OOM-killer срабатывает слишком поздно: машина успевает уйти в свап и перестать отвечать даже по SSH. Демон из пакета earlyoom бьёт раньше и выборочно — в /etc/default/earlyoom:
EARLYOOM_ARGS="-m 6 -r 3600 --avoid '(^|/)(dockerd|sshd|systemd|coolify)$' --prefer '(^|/)(node|next|esbuild|cc1plus)$'"
При падении свободной памяти ниже 6% будет убит процесс сборки, а не панель и не ваш SSH.
Выносить сборку. Самый чистый способ снять пики — не собирать на проде. У Coolify два варианта: собирать образ на отдельном сервере, помеченном как build server, либо принимать готовый образ из реестра, собранный в GitHub Actions. Во втором случае запас под сборку продовой машине не нужен вовсе.
Как измерить свою потребность и поймать OOM
Таблицы дают ориентир, но своя цифра точнее. Сначала снимите базовую линию в простое, когда все приложения подняты и сборок не идёт: free -m плюс docker stats --no-stream. Затем поймайте пик — запустите в отдельной сессии перед нажатием Deploy:
while true; do date +%T; free -m | awk 'NR==2{print $3" used, "$7" available"}'; sleep 5; done
Минимальное available за время сборки — и есть ваш реальный запас. Опускалось ниже 300–400 МБ — вы жили на грани, и следующая сборка с чуть большим бандлом не пройдёт.
Разложить потребление по группам процессов помогает systemd-cgtop -m --order=memory, а историю нехваток — журнал ядра:
journalctl -k --since "7 days ago" | grep -iE "oom|killed process"
Пустой вывод за неделю активных деплоев — хороший знак. Несколько строк — сигнал, что вы уже проезжали по краю.
Порог для апгрейда простой: если available в пике сборки стабильно ниже 15% от объёма памяти или в журнале появляются OOM — добавляйте RAM. Тюнинг на этом этапе покупает 10–15%, а не следующий уровень.
Какой сервер взять в MAATRIX под Coolify
Считаем снизу вверх, без округления в свою пользу.
Минимум, который имеет право на жизнь: 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe. Панель забирает 1,15 ГБ, хост — ещё 0,25 ГБ, остальные 2,6 ГБ ваши. Работает при трёх условиях: swap-файл на 4 ГБ, сборки по одной за раз, никакого MySQL. Годится для личных проектов, стенда, пары небольших сервисов.
Комфортный вариант: 4 vCPU, 8 ГБ RAM, 100–160 ГБ NVMe. Панель, 4–6 приложений с базами и сборка, которая не мешает проду. Эту конфигурацию мы советуем чаще всего: она закрывает и запас под пик, и скорость сборки — лишние два ядра сокращают деплой Next.js с пяти минут до полутора.
Тяжёлый режим: 8 vCPU, 16 ГБ, 200+ ГБ NVMe. Нужен при Angular или Rust, нескольких деплоях в день, десятке сервисов или базе, которой мало 2 ГБ. Экономная альтернатива — держать панель на маленькой машине, а приложения разложить по отдельным серверам: Coolify управляет ими по SSH, и обновление панели не касается прода.
Локация — Лондон, причина сугубо практическая. Сборка постоянно ходит наружу: образы с Docker Hub и ghcr.io, пакеты с npm и PyPI, код с GitHub. С российских адресов часть реестров отвечает отказом или работает через раз, и чинить вы будете не память, а таймауты failed to fetch. Британская площадка ходит везде без ухищрений, пинг из Москвы 45–60 мс — для веб-панели неотличимо от локальной. Франция — равноценная альтернатива при аудитории в континентальной Европе; Россию берут, когда персональные данные обязаны храниться в РФ по 152-ФЗ.
Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер стоит в Лондоне. Не уверены в конфигурации — напишите, сколько приложений планируете и на каком стеке, посчитаем вместе. Смежное чтение: Coolify против Dokploy.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Coolify
Нужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Изображения и ВидеоАудио и звукИИ MAAT — Собеседник
#x27; --prefer '(^|/)(node|next|esbuild|cc1plus)
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Coolify
Сборка — вот где память кончается
Типичная картина: панель работает неделю, всё зелёное, вы жмёте Deploy — и лог обрывается на шаге npm run build:
#12 [builder 5/5] RUN npm run build
#12 CANCELED
------
failed to solve: process "/bin/sh -c npm run build" did not complete successfully: exit code: 137
137 — это 128 + 9, то есть SIGKILL. Убил процесс не Docker и не Coolify, а ядро; подтверждение даёт dmesg -T | grep -i "killed process":
[Tue Aug 25 03:11:47 2026] Out of memory: Killed process 24193 (node) total-vm:4210332kB,
anon-rss:1683244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:6540kB oom_score_adj:0
Точечная проверка контейнера — docker inspect --format '{{.State.OOMKilled}}' <container_id>. Ответ true закрывает вопрос: это память, и правки Dockerfile тут не помогут. Разбор соседних симптомов — в материале про частые ошибки Coolify.
Сколько просит сборка — зависит от стека. Замеры пиковой резидентной памяти сборочного контейнера на средних проектах:
Стек
Пик сборки
Что съедает
Статика на Vite/React
0,7–1,4 ГБ
Rollup держит граф модулей в памяти
Next.js 15, 30–50 маршрутов
1,8–2,6 ГБ
Компиляция + типы + пререндер страниц
Nuxt 3
1,6–2,4 ГБ
Двойная сборка: клиент и сервер
Angular, production build
2,5–4,0 ГБ
Прожорливее всех фронтендов
Laravel + composer + vite
0,9–1,5 ГБ
Пик даёт фронтенд, не PHP
Python / FastAPI
0,25–0,6 ГБ
Обычно просто установка колёс
Go, multi-stage
0,4–0,9 ГБ
Зависит от числа пакетов
Rust, cargo build --release
1,5–3,0 ГБ
LLVM на оптимизациях
Java Spring, Gradle
1,5–2,5 ГБ
JVM демона сборки
Отсюда и берётся правило: сервер на 4 ГБ, у которого 1,4 ГБ занято базой, оставляет сборке около 2,5 ГБ доступной памяти. Next.js в них попадает, но впритык, а Angular — уже нет.
Полумера, которая часто спасает, — ограничить кучу Node переменной сборки (Environment Variables, галочка Build variable): NODE_OPTIONS=--max-old-space-size=1536. Честно про минус: памяти это не добавляет, а меняет форму отказа. Вместо убийства процесса ядром вы получите управляемое FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory, и на большом проекте сборка всё равно не закончится. Зато сервер и панель выживут, а не уйдут в swap-шторм.
Сколько добавляет каждое приложение и база
Пик сборки разовый, а рантайм живёт постоянно и определяет, сколько сервисов поместится. Ориентиры на реальных контейнерах:
Node / Next.js в standalone-режиме — 120–250 МБ на инстанс.
PHP-FPM, пул на 5 воркеров — 250–400 МБ, каждый воркер держит свой интерпретатор.
Python + uvicorn, 2 воркера — 150–300 МБ.
Go-бинарник — 15–60 МБ, лучший сосед на маленьком сервере.
PostgreSQL 16, до 10 соединений — 180–350 МБ.
MySQL 8 — 400–500 МБ сразу после старта, даже пустой. При жёстком бюджете берите Postgres.
Redis без данных — 15–40 МБ, растёт вместе с ключами, если не задан maxmemory.
Две вещи, на которых спотыкаются. Базы из панели стартуют с дефолтным конфигом образа: shared_buffers = 128MB на 4 ГБ — нормально, но десять таких баз рядом — полтора гигабайта впустую. И Redis без maxmemory растёт, пока не упрётся в память хоста, а OOM-killer выберет жертвой не его, а самый крупный процесс — вашу базу или панель.
Практическое правило для планирования: постоянное потребление = 1,4 ГБ (Coolify и хост) + сумма рантаймов ваших сервисов, а свободного оставляйте не меньше, чем пик самой тяжёлой сборки.
Как выжить на 4 ГБ: swap, zram и лимиты
Swap-файл — обязательный минимум, он разобран в статье про установку и настройку Coolify на VPS. Здесь — то, что делают поверх него.
zram вместо (или вместе с) файла подкачки. Сжатый swap в памяти в разы быстрее дискового и хорошо ложится на сборки, где много однотипных данных. Ставим apt install -y zram-tools и правим /etc/default/zramswap:
ALGO=zstd
PERCENT=50
PRIORITY=100
Дальше systemctl restart zramswap. На 4 ГБ это даёт 2 ГБ сжатого пространства с коэффициентом 2,5–3. Приоритет 100 ставит zram выше дискового swap. Плата — CPU на сжатие, а он на сборке и так узкое место.
Подкрутить sysctl в /etc/sysctl.d/99-coolify.conf, применить sysctl --system:
vm.swappiness=10
vm.vfs_cache_pressure=50
vm.overcommit_memory=0
swappiness=10 не запрещает swap, а откладывает его до реальной нужды. А вот популярный совет поставить vm.overcommit_memory=1 для сервера сборок вреден: он разрешает выдавать память, которой нет, и вместо честного отказа вы получите сервер, зависший на минуты.
Лимиты на приложения. В карточке приложения есть Advanced → лимиты ресурсов, под капотом это докеровские --memory и --memory-swap. В своём compose то же самое:
deploy:
  resources:
    limits:
      memory: 512M
Смысл в изоляции: контейнер с утечкой умрёт сам и перезапустится, а не утащит панель. Минус честный — его убьют ровно на лимите, даже если на сервере есть свободная память.
earlyoom, чтобы сервер не вис. Штатный OOM-killer срабатывает слишком поздно: машина успевает уйти в свап и перестать отвечать даже по SSH. Демон из пакета earlyoom бьёт раньше и выборочно — в /etc/default/earlyoom:
EARLYOOM_ARGS="-m 6 -r 3600 --avoid '(^|/)(dockerd|sshd|systemd|coolify)$' --prefer '(^|/)(node|next|esbuild|cc1plus)$'"
При падении свободной памяти ниже 6% будет убит процесс сборки, а не панель и не ваш SSH.
Выносить сборку. Самый чистый способ снять пики — не собирать на проде. У Coolify два варианта: собирать образ на отдельном сервере, помеченном как build server, либо принимать готовый образ из реестра, собранный в GitHub Actions. Во втором случае запас под сборку продовой машине не нужен вовсе.
Как измерить свою потребность и поймать OOM
Таблицы дают ориентир, но своя цифра точнее. Сначала снимите базовую линию в простое, когда все приложения подняты и сборок не идёт: free -m плюс docker stats --no-stream. Затем поймайте пик — запустите в отдельной сессии перед нажатием Deploy:
while true; do date +%T; free -m | awk 'NR==2{print $3" used, "$7" available"}'; sleep 5; done
Минимальное available за время сборки — и есть ваш реальный запас. Опускалось ниже 300–400 МБ — вы жили на грани, и следующая сборка с чуть большим бандлом не пройдёт.
Разложить потребление по группам процессов помогает systemd-cgtop -m --order=memory, а историю нехваток — журнал ядра:
journalctl -k --since "7 days ago" | grep -iE "oom|killed process"
Пустой вывод за неделю активных деплоев — хороший знак. Несколько строк — сигнал, что вы уже проезжали по краю.
Порог для апгрейда простой: если available в пике сборки стабильно ниже 15% от объёма памяти или в журнале появляются OOM — добавляйте RAM. Тюнинг на этом этапе покупает 10–15%, а не следующий уровень.
Какой сервер взять в MAATRIX под Coolify
Считаем снизу вверх, без округления в свою пользу.
Минимум, который имеет право на жизнь: 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe. Панель забирает 1,15 ГБ, хост — ещё 0,25 ГБ, остальные 2,6 ГБ ваши. Работает при трёх условиях: swap-файл на 4 ГБ, сборки по одной за раз, никакого MySQL. Годится для личных проектов, стенда, пары небольших сервисов.
Комфортный вариант: 4 vCPU, 8 ГБ RAM, 100–160 ГБ NVMe. Панель, 4–6 приложений с базами и сборка, которая не мешает проду. Эту конфигурацию мы советуем чаще всего: она закрывает и запас под пик, и скорость сборки — лишние два ядра сокращают деплой Next.js с пяти минут до полутора.
Тяжёлый режим: 8 vCPU, 16 ГБ, 200+ ГБ NVMe. Нужен при Angular или Rust, нескольких деплоях в день, десятке сервисов или базе, которой мало 2 ГБ. Экономная альтернатива — держать панель на маленькой машине, а приложения разложить по отдельным серверам: Coolify управляет ими по SSH, и обновление панели не касается прода.
Локация — Лондон, причина сугубо практическая. Сборка постоянно ходит наружу: образы с Docker Hub и ghcr.io, пакеты с npm и PyPI, код с GitHub. С российских адресов часть реестров отвечает отказом или работает через раз, и чинить вы будете не память, а таймауты failed to fetch. Британская площадка ходит везде без ухищрений, пинг из Москвы 45–60 мс — для веб-панели неотличимо от локальной. Франция — равноценная альтернатива при аудитории в континентальной Европе; Россию берут, когда персональные данные обязаны храниться в РФ по 152-ФЗ.
Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер стоит в Лондоне. Не уверены в конфигурации — напишите, сколько приложений планируете и на каком стеке, посчитаем вместе. Смежное чтение: Coolify против Dokploy.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Coolify
Нужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Изображения и ВидеоАудио и звукИИ MAAT — Собеседник
#x27;"

При падении свободной памяти ниже 6% будет убит процесс сборки, а не панель и не ваш SSH.

Выносить сборку. Самый чистый способ снять пики — не собирать на проде. У Coolify два варианта: собирать образ на отдельном сервере, помеченном как build server, либо принимать готовый образ из реестра, собранный в GitHub Actions. Во втором случае запас под сборку продовой машине не нужен вовсе.

Как измерить свою потребность и поймать OOM

Таблицы дают ориентир, но своя цифра точнее. Сначала снимите базовую линию в простое, когда все приложения подняты и сборок не идёт: free -m плюс docker stats --no-stream. Затем поймайте пик — запустите в отдельной сессии перед нажатием Deploy:

while true; do date +%T; free -m | awk 'NR==2{print 
" used, "$7" available"}'; sleep 5; done

Минимальное available за время сборки — и есть ваш реальный запас. Опускалось ниже 300–400 МБ — вы жили на грани, и следующая сборка с чуть большим бандлом не пройдёт.

Разложить потребление по группам процессов помогает systemd-cgtop -m --order=memory, а историю нехваток — журнал ядра:

journalctl -k --since "7 days ago" | grep -iE "oom|killed process"

Пустой вывод за неделю активных деплоев — хороший знак. Несколько строк — сигнал, что вы уже проезжали по краю.

Порог для апгрейда простой: если available в пике сборки стабильно ниже 15% от объёма памяти или в журнале появляются OOM — добавляйте RAM. Тюнинг на этом этапе покупает 10–15%, а не следующий уровень.

Какой сервер взять в MAATRIX под Coolify

Считаем снизу вверх, без округления в свою пользу.

Минимум, который имеет право на жизнь: 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe. Панель забирает 1,15 ГБ, хост — ещё 0,25 ГБ, остальные 2,6 ГБ ваши. Работает при трёх условиях: swap-файл на 4 ГБ, сборки по одной за раз, никакого MySQL. Годится для личных проектов, стенда, пары небольших сервисов.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 100–160 ГБ NVMe. Панель, 4–6 приложений с базами и сборка, которая не мешает проду. Эту конфигурацию мы советуем чаще всего: она закрывает и запас под пик, и скорость сборки — лишние два ядра сокращают деплой Next.js с пяти минут до полутора.

Тяжёлый режим: 8 vCPU, 16 ГБ, 200+ ГБ NVMe. Нужен при Angular или Rust, нескольких деплоях в день, десятке сервисов или базе, которой мало 2 ГБ. Экономная альтернатива — держать панель на маленькой машине, а приложения разложить по отдельным серверам: Coolify управляет ими по SSH, и обновление панели не касается прода.

Локация — Лондон, причина сугубо практическая. Сборка постоянно ходит наружу: образы с Docker Hub и ghcr.io, пакеты с npm и PyPI, код с GitHub. С российских адресов часть реестров отвечает отказом или работает через раз, и чинить вы будете не память, а таймауты failed to fetch. Британская площадка ходит везде без ухищрений, пинг из Москвы 45–60 мс — для веб-панели неотличимо от локальной. Франция — равноценная альтернатива при аудитории в континентальной Европе; Россию берут, когда персональные данные обязаны храниться в РФ по 152-ФЗ.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер стоит в Лондоне. Не уверены в конфигурации — напишите, сколько приложений планируете и на каком стеке, посчитаем вместе. Смежное чтение: Coolify против Dokploy.

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