Dokploy на сервере: частые ошибки и решения

MAATRIX

Пока Dokploy работает, он выглядит как Heroku за одну команду. Ломается тоже по-своему: панель на 3000 порту молчит, Traefik на все домены отдаёт 404 page not found, а Docker выдаёт «the swarm does not have a leader». Почти все ошибки Dokploy лежат в одном из четырёх слоёв — Swarm, Traefik, сеть контейнеров и диск. Ниже — как за минуту понять слой и что в нём чинить.

С чего начинать разбор ошибок Dokploy

Dokploy — не один процесс: панель dokploy работает как сервис Docker Swarm, а Postgres, Redis и Traefik — как обычные контейнеры. Поэтому docker ps показывает три сущности из четырёх, и человек решает, что панель пропала.

docker service ls                                  # dokploy  replicated  1/1
docker ps --format 'table {{.Names}}\t{{.Status}}' # dokploy-traefik/-postgres/-redis
docker info --format '{{.Swarm.LocalNodeState}}'   # active

REPLICAS 0/1 — вам в раздел про Swarm. Нет контейнера dokploy-traefik — в раздел про домены. Всё на месте, а сайт не открывается — смотрите сеть.

Логи читаются двумя командами: у сервиса docker service logs dokploy --tail 200 -f, у контейнеров docker logs dokploy-traefik -f. Перезапуск панели — не docker restart, а docker service update --force dokploy: Swarm пересоздаёт задачу, обычный restart он молча откатит.

Панель не открывается на :3000

Сервис не запущен. Смотрите последнюю задачу с полным текстом ошибки:

docker service ps dokploy --no-trunc
NAME        NODE      DESIRED STATE   CURRENT STATE           ERROR
dokploy.1   vps-uk1   Running         Pending 4 minutes ago   "no suitable node
(insufficient resources on 1 node)"

insufficient resources — нет свободной памяти под задачу, обычно машину занял процесс сборки. No such image: dokploy/dokploy:latest — не скачался образ, проверьте docker pull руками. Пустая колонка ERROR при Running значит, что дело в сети.

Порт закрыт снаружи. ss -tlnp | grep ':3000 ' показывает слушателя, а снаружи глухо — это UFW или облачный фаервол провайдера: ufw allow 22/tcp, ufw allow 80/tcp, ufw allow 443/tcp, ufw allow 3000/tcp. Тонкость, на которой теряют часы: опубликованные контейнерами порты правила UFW обходят — DNAT попадает в цепочку DOCKER-USER раньше пользовательских правил. Порты 80 и 443 откроются сами, а 3000 у панели — обычный порт хост-процесса, и UFW ему подчиняется. Снаружи curl -o /dev/null -w '%{http_code}\n' http://ВАШ_IP:3000 должен вернуть 200.

Домен отдаёт 502, а по IP всё живо — сломан Traefik, а не панель. Прямой вход http://IP:3000 работает всегда, даже если сертификат для домена панели не выпустился.

Swarm без лидера, нода Down и смена IP

Самая пугающая группа: команды Docker отвечают текстом, который читается как «кластер развалился».

Error response from daemon: rpc error: code = Unknown desc = The swarm does not
have a leader. It's possible that too few managers are online.

На одиночном сервере причина почти всегда одна: сменился IP-адрес, который Swarm анонсировал при инициализации — переезд на другой тариф, поднятый WireGuard, перезагрузка с динамическим адресом. Менеджер стучится к себе по старому адресу и не собирает кворум. Сверьте:

docker info --format '{{.Swarm.NodeAddr}}'
ip -4 -o addr show scope global | awk '{print 
Нужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Изображения и ВидеоАудио и звукИИ MAAT — Собеседник
, $4}'

Адреса разошлись — лечится одной командой, без потери приложений:

docker swarm init --force-new-cluster --advertise-addr 203.0.113.10

Она пересобирает Raft из локального состояния: сервисы, сети и тома на месте, панель поднимется сама.

Вторая история — docker node ls показывает Drain вместо Active: узел помечен как «не размещать здесь задачи», и все сервисы схлопываются в 0/1. Режим ставят на время обслуживания и забывают вернуть — docker node update --availability active vps-uk1.

Чего не надо делать в панике — docker swarm leave --force: команда снимает с узла все сервисы разом, гася и прод, и панель. Восстановиться можно, тома и /etc/dokploy остаются, но это полчаса простоя вместо тридцати секунд --force-new-cluster. Другие грабли кластера — Docker Swarm на сервере.

Домен, Traefik и сертификат Let's Encrypt

404 page not found — собственная страница Traefik: запрос дошёл, ни один роутер не подошёл. Причины: домен не привязан к приложению, не тот порт в Domains, контейнер не в сети dokploy-network. Смотрите конфиг, который сгенерировала панель:

cat /etc/dokploy/traefik/dynamic/my-app.yml
docker logs dokploy-traefik --tail 100 | grep -iE 'error|acme'

Порт в servers.url должен совпадать с реальным портом контейнера. Классика — приложение слушает 8080, а в поле Container Port осталось 3000.

Сертификат не выпускается. Дословный лог:

level=error msg="Unable to obtain ACME certificate for domains \"app.example.com\":
[app.example.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized ::
Invalid response from http://app.example.com/.well-known/acme-challenge/7Xb2q: 404"

Четыре причины закрывают почти всё:

• DNS смотрит не туда. dig +short app.example.com @1.1.1.1 должен совпасть с curl -s ifconfig.me.
• Cloudflare с «Always Use HTTPS». Он редиректит HTTP-проверку на HTTPS, а сертификата ещё нет — круг замкнулся. Выключите оранжевое облако до выпуска или переходите на DNS-01.
• 80 порт занят. HTTP-01 требует именно его. Если на сервере уже стоял Nginx, Traefik не поднялся вообще: Bind for 0.0.0.0:80 failed: port is already allocated. Смотрите ss -tlnp | grep ':80 '.
• Права на acme.json. После копирования файла руками в логе будет permissions 644 for /etc/dokploy/traefik/dynamic/acme.json are too open, please use 600. Лечится chmod 600 и docker restart dokploy-traefik.

И главное: не гоняйте деплой по кругу, пока сертификат не выпускается. У Let's Encrypt лимит в 5 неудачных проверок на домен в час — дальше придёт too many failed authorizations recently, даже если причина уже устранена. Отлаживайте на поддомене вроде test.example.com. Поведение прокси — частые ошибки Traefik.

Приложение не видит базу, а порты конфликтуют

Всё живёт в overlay-сети dokploy-network, а имена берутся из панели, а не из compose-файла.

getaddrinfo ENOTFOUND postgres или, в питоновском варианте, could not translate host name "postgres" to address: Name or service not known. Когда базу создаёт панель, её внутреннее имя выглядит как my-postgres-a1b2c3 и показано в карточке базы полем Internal Host. Строка подключения должна быть postgresql://user:pass@my-postgres-a1b2c3:5432/dbname, не @localhost и не @postgres. Кто вообще в этой сети:

docker network inspect dokploy-network --format '{{range .Containers}}{{.Name}} {{end}}'

Контейнера приложения нет в выводе — он не в общей сети. Типично для деплоя через Compose со своими networks:; лечится внешней сетью:

networks:
  dokploy-network:
    external: true

Конфликт портов. В Swarm публикация порта — свойство всего кластера, и второй сервис с тем же портом не создастся: port '3000' is already in use by service 'my-app'. Практический вывод: не публикуйте порты приложений вообще, доступ давайте через домен и Traefik.

Место, память и обновления, которые ломают панель

Третий класс — не поломка, а износ: выглядит как внезапная деградация исправного сервера.

no space left on device вылезает где угодно — в логе сборки как failed to register layer, в панели как молча падающий деплой. Через месяц работы:

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          63        11        24.7GB    17.2GB (69%)
Build Cache     412       0         11.8GB    11.8GB (100%)

Место съедают старые образы и кэш BuildKit. Безопасная чистка — docker builder prune -af --filter until=168h и docker image prune -af --filter until=336h. И никогда не запускайте здесь docker system prune -a --volumes: флаг удаляет тома, не подключённые к запущенным контейнерам, то есть данные любой базы, которая сейчас остановлена (почему Docker занимает всё место).

Панель убита по OOM. Сервис сам собой перезапускается, docker service ps dokploy показывает Shutdown с кодом 137, подтверждение — в ядре: dmesg -T | grep -i 'killed process'. В простое Dokploy скромен, замер docker stats --no-stream на машине с 4 ГБ: dokploy 402 МиБ, dokploy-postgres 118 МиБ, dokploy-traefik 62 МиБ, dokploy-redis 14 МиБ — около 600 МБ, с мониторингом 0,7–0,9 ГБ. Убивает совпадение: сборка плюс rolling update, при котором Swarm держит старую и новую задачи разом и требует двойной памяти. Лечение — режим «сначала погасить» для тяжёлых сервисов: docker service update --update-order stop-first my-app. Swap на 2–4 ГБ обязателен, расчёт памяти — сколько RAM нужно для Dokploy.

Обновление сломало панель. Dokploy на конец лета 2026 всё ещё в ветке 0.2x, ломающие изменения между релизами случаются. Swarm хранит предыдущую спецификацию, поэтому образ откатывается командой docker service rollback dokploy. Но откат не отменяет миграции базы — они односторонние. Перед обновлением снимайте снапшот или хотя бы дамп:

docker exec dokploy-postgres pg_dump -U dokploy -d dokploy -Fc > /root/dokploy-$(date +%F).dump
tar czf /root/dokploy-etc-$(date +%F).tar.gz /etc/dokploy

Этих двух файлов хватает, чтобы поднять панель со всеми приложениями на новом сервере. Данные приложений в них не входят — для баз настраивайте бэкапы в S3.

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

Половина разобранного выше — не баги, а следствие тесной машины: OOM при обновлении, insufficient resources у задачи, забитый диск. Конфигурация — часть профилактики.

Минимум: 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe и swap на 4 ГБ. Приложениям остаётся около 3,1 ГБ — одно-два небольших с базой, если сборки идут по очереди. Ограничение честное: двойной расход памяти при rolling update здесь кусается, для тяжёлых сервисов придётся руками ставить --update-order stop-first, теряя главный плюс Swarm. Варианта «2 ГБ» хватает ровно на то, чтобы панель открылась: первая же сборка фронтенда закончится exit code: 137.

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

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

Как это выглядит при заказе. Dokploy есть в каталоге приложений MAATRIX и при заказе сервера устанавливается автоматически — вставлять команды из этой статьи вручную не нужно. Автоустановка работает на Ubuntu и Debian, включая Ubuntu 24.04 LTS; Swarm инициализируется сразу с корректным --advertise-addr, так что ошибка из раздела про кластер вас не коснётся. Доступы к панели появляются в личном кабинете в разделе «Доступ» — останется привязать домен и подключить репозиторий. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер в Лондоне. Если ещё выбираете панель — Coolify против Dokploy.

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