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

MAATRIX

В документации минимумом названы 2 ГБ — честно ровно для того, чтобы панель поднялась и показала пустой дашборд. Дальше вступает то, чего у обычной панели нет: Dokploy переводит сервер в Docker Swarm, а Swarm при каждом редеплое держит в памяти сразу старую и новую копию приложения. Сверху ложится пик сборки. Разберём требования Dokploy по памяти по граммам, с командами и текстами ошибок.

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

Цифры для чистого сервера, где кроме панели ничего нет.

Главное: память под Dokploy — это не одна цифра, а три. Потребление в простое, разовый пик сборки на три-четыре минуты и пик редеплоя, когда Swarm поднимает новую задачу, не погасив старую. Третий пункт отличает Dokploy от любой другой панели, и именно он роняет машины на 4 ГБ: сервер падает на наложении второго пика на третий. Процессор определяет только время: Next.js 15 на 2 vCPU собирается 4–6 минут, на 4 vCPU — полторы-две.

Куда уходит память в простое: четыре контейнера и налог на Swarm

После установки Dokploy поднимает четыре служебных контейнера:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}"
NAME                     MEM USAGE / LIMIT
dokploy.1.k7x2m9v4h1qz   231.4MiB / 7.752GiB
dokploy-postgres          88.7MiB / 7.752GiB
dokploy-traefik           41.2MiB / 7.752GiB
dokploy-redis             11.9MiB / 7.752GiB

Итого 370 МиБ — до того, как вы задеплоили хоть что-то. Обратите внимание на имя первого контейнера: dokploy.1.k7x2m9v4h1qz, а не dokploy. Панель сама запущена как Swarm-сервис, поэтому docker restart dokploy не сработает — нужен docker service update --force dokploy.

Дальше то, о чём забывают: Swarm делает дороже сам демон. В обычном режиме dockerd держит 90–130 МБ RSS, в режиме менеджера кластера — 150–230 МБ: поднимается raft-хранилище состояния, планировщик и сверщик задач (ps -o rss= -p $(pgrep -x dockerd) на нашем стенде даёт 198 МБ). Плюс containerd 40–60 МБ и по 8–12 МБ на shim контейнера. Итог по free -m на восьмигигабайтной машине:

               total        used        free      shared  buff/cache   available
Mem:            7943         812        5904          17        1226        6853

0,8 ГБ занято, 6,8 ГБ доступно. Смотрите на available, а не на free: в buff/cache дисковый кэш, который ядро отдаст по требованию. Coolify на том же стенде занимает 1,2–1,4 ГБ (Coolify против Dokploy). Включённые метрики сервера добавят контейнер и 60–120 МБ плюс базу в /etc/dokploy/monitoring — на 2 ГБ от них лучше отказаться.

Редеплой стоит двойной памяти: главная особенность Dokploy

Вот механика, из-за которой требования Dokploy выше, чем кажется по docker stats. Панель настраивает сервисы на обновление в порядке «сначала подними новое» — docker service inspect myapp-a1b2c3 --format '{{.Spec.UpdateConfig.Order}}' вернёт start-first. Swarm запускает новую задачу, дожидается её health check и только потом гасит старую — ноль простоя без единой настройки. Плата — в момент обновления в памяти живут обе копии приложения.

Считаем. VPS 4 ГБ, база платформы 0,8 ГБ, Next.js в рантайме держит 380 МБ, рядом Postgres на 260 МБ — в простое 1,44 ГБ, вроде вольготно. Деплой: сборка Nixpacks на пике 2,1 ГБ, старая задача 0,38 ГБ, новая прогревается — ещё 0,38 ГБ. Итого 3,9 ГБ при физических 4. Дальше как повезёт со swap. Не повезёт — увидите это:

docker service ps --no-trunc myapp-a1b2c3
ID       NAME                  DESIRED STATE  CURRENT STATE           ERROR
p2k9r1   myapp-a1b2c3.1        Running        Running 9 seconds ago
n8f3wd    \_ myapp-a1b2c3.1    Shutdown       Failed 44 seconds ago   "task: non-zero exit (137)"
j1v7qs    \_ myapp-a1b2c3.1    Shutdown       Failed 2 minutes ago    "task: non-zero exit (137)"

137 = 128 + 9, SIGKILL от ядра. И в отличие от обычного Docker, Swarm задачу перезапустит, а перезапуск снова требует памяти. Получается цикл OOM → рестарт → OOM: приложение в панели мигает зелёным и красным, сервер уходит в swap-шторм. Лечится одной командой — переводом сервиса в режим «сначала погасить»:

docker service update --update-order stop-first --update-parallelism 1 myapp-a1b2c3

Вы получаете 3–10 секунд простоя вместо двойного расхода памяти — на 4 ГБ это правильный размен; на 8 ГБ оставляйте start-first. Второй множитель того же рода — реплики: docker service scale myapp-a1b2c3=2 удваивает рантайм постоянно, а при start-first на время обновления утраивает.

Сборка: второй пик, и он зависит от способа сборки

Dokploy клонирует репозиторий в /etc/dokploy/applications/<имя>/code и собирает образ на хосте через BuildKit — вне Swarm и без лимитов сервиса. Настройки ресурсов приложения на сборку не влияют.

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

Что виновата память, а не код, подтвердит dmesg -T | grep -i "killed process": там будет Out of memory: Killed process 31844 (node) ... anon-rss:1902116kB.

У Dokploy четыре способа сборки, и стоят они по-разному. Пиковый RSS на среднем Node-проекте (40 маршрутов, 900 зависимостей):

Вывод: на 4 ГБ первым делом уходите с buildpacks на свой Dockerfile. Это экономит больше гигабайта пика и фиксирует версию рантайма, которая у Nixpacks может молча съехать при обновлении. Быстрая полумера — пометить NODE_OPTIONS=--max-old-space-size=1536 как build-time-переменную: памяти не добавит, но заменит убийство ядром на управляемое FATAL ERROR: Reached heap limit.

Под нехватку RAM маскируется и кэш BuildKit: забив диск, он роняет сборку с другим текстом. Чистите docker builder prune -f --keep-storage 10GB (почему Docker занимает всё место).

Рантайм: приложения, базы и множитель preview-окружений

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

• Node / Next.js в standalone-режиме — 120–250 МБ, у Nuxt выше. Go-бинарник в scratch-образе — 15–60 МБ, лучший сосед на маленьком сервере.
• PostgreSQL 17 из панели — 180–350 МБ на десятке соединений, shared_buffers по умолчанию 128 МБ.
• MySQL 8 — 400–500 МБ сразу после старта, даже пустой; при жёстком бюджете берите Postgres.
• MongoDB 7 — 350–600 МБ: WiredTiger берёт половину свободной памяти минус гигабайт, пока не задан --wiredTigerCacheSizeGB.
• Redis без maxmemory — стартует с 15–40 МБ и растёт до упора, а OOM-killer выберет жертвой не его, а самый крупный процесс — базу.

Отдельный пункт, регулярно съедающий сервер, — preview-окружения. Dokploy поднимает копию приложения на каждый открытый пул-реквест: свой домен, свои контейнеры и, если в стеке есть база, своя база. Пять живых PR при рантайме 250 МБ и базе 200 МБ — 2,25 ГБ, которых никто не планировал. Лимит превью есть в настройках; ставьте 2–3.

Формула: постоянное = 0,8 ГБ (панель и хост) + сумма рантаймов + превью, а свободного — не меньше, чем пик тяжелейшей сборки + рантайм крупнейшего приложения. Второе слагаемое и есть Swarm-налог.

Лимиты Swarm, swap и как поймать свой пик

В карточке приложения, вкладка Advanced, блок Resources — поля Memory Reservation и Memory Limit; под капотом это docker service update --reserve-memory 256M --limit-memory 512M myapp-a1b2c3. Разница между полями принципиальная. Limit — жёсткий потолок: упёршаяся в него задача получает SIGKILL, и Swarm поднимает её заново; аналога --memory-swap у сервисов Swarm нет, смягчить свопом нельзя. Reservation — не гарантия памяти, а условие планирования: Swarm не запустит задачу, если на узле не осталось нераспределённого резерва. Отсюда фирменная ошибка, когда память вроде есть, а сервис висит:

docker service ps myapp-a1b2c3
ID       NAME             DESIRED STATE  CURRENT STATE           ERROR
w4d1he   myapp-a1b2c3.1   Running        Pending 4 minutes ago   "no suitable node (insufficient resources on 1 node)"

Держите сумму резервов всех сервисов ниже физической памяти минус гигабайт на панель и хост. Swap обязателен, но это страховка от пика, а не ёмкость: 4 ГБ на машинах до 8 ГБ (правильный размер swap) плюс vm.swappiness=10.

Специфичный для Swarm риск: уход в своп запускает лавину редеплоев. Пока узел свопится, health check не отвечает вовремя, Swarm считает задачу нездоровой и пересоздаёт её — а пересоздание при start-first требует двойной памяти. Один сборочный пик превращается в получасовой цикл рестартов. Поэтому на 4 ГБ stop-first и увеличенный --health-start-period стоят дороже, чем звучат.

Свою цифру измеряйте: перед нажатием Deploy запустите while true; do free -m | awk 'NR==2{print $7}'; sleep 5; done. Минимальное available за деплой и есть реальный запас; ниже 300–400 МБ — вы на грани. Историю нехваток даст journalctl -k --since "7 days ago" | grep -i oom.

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

Считаем снизу вверх.

Минимум, имеющий право на жизнь: 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe плюс swap на 4 ГБ. Панель с хостом забирают 0,8 ГБ, вам остаётся 3,1. Работает при трёх условиях: сборки по одной, редеплой в режиме stop-first, никаких MySQL и MongoDB рядом. Годится для пет-проекта, стенда, двух-трёх сервисов.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 100–160 ГБ NVMe. Панель, 5–7 сервисов с базами, пара превью и сборка, не мешающая проду. Здесь можно оставить start-first: двойной пик на 8 ГБ уже не кусается. Диск с запасом — за месяц активных деплоев в /var/lib/docker набегает 15–25 ГБ образов и кэша.

Тяжёлый режим: 8 vCPU, 16 ГБ, 200+ ГБ NVMe. Нужен при Angular, Rust или JVM в сборке, десятке сервисов, превью на каждый PR либо базе, которой мало 2 ГБ. Дешевле разнести роли: маленькая машина под панель, отдельные узлы под приложения — Dokploy добавляет их Swarm-воркерами, но узлам понадобится приватная связность для портов 2377, 7946 и 4789 (Docker Swarm на VPS).

Ставить ничего не придётся. Dokploy есть в каталоге apps.maatrix.io: при заказе сервера он разворачивается автоматически на чистой Ubuntu или Debian — со Swarm, Traefik и служебными контейнерами. Логин, пароль и адрес панели появляются в кабинете, раздел «Доступ»: заходите на порт 3000 и добавляете приложение.

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

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

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