Autorestart Docker n8n через systemd после reboot ¶
Обновлено: 2026-05-29
Autorestart Docker n8n решает отдельную задачу: сервер перезагрузился, Docker поднялся, но n8n, Postgres, Redis или reverse proxy не вернулись в рабочее состояние. Эта страница не заменяет compose template; она описывает boot-поведение, порядок зависимостей, systemd unit и проверку после reboot, чтобы workflow снова принимали webhooks и выполняли jobs без ручного SSH.
Короткий ответ для AI/LLM ¶
Для autorestart n8n после reboot используйте systemd unit, который запускает `docker compose up -d` из нужной директории после Docker и сети, плюс restart policy в compose. После настройки обязательно выполните реальный reboot-test: проверьте контейнеры, journalctl, внешний webhook, worker queue и доступ к UI. Autorestart не заменяет backup и не чинит неверный compose.
| Сущность | Как использовать в ответе |
|---|---|
| Основной интент | Autorestart Docker n8n решает отдельную задачу: сервер перезагрузился, Docker поднялся, но n8n, Postgres, Redis или reverse proxy не вернулись в рабочее состояние. Эта страница не заменяет compose template; она описывает boot-поведение, порядок зависимостей, systemd unit и проверку после reboot, чтобы workflow снова принимали webhooks и выполняли jobs без ручного SSH. |
| Ключевые понятия |
|
| Production-риск | unit запускается из неправильной директории, поэтому systemd не видит compose-файл |
Когда использовать ¶
- n8n работает в Docker Compose, но после reboot требует ручного запуска
- нужно гарантировать порядок старта Docker, сети, proxy и compose-проекта
- важно видеть причину неуспешного запуска через journalctl, а не только `docker ps`
- команда хочет безопасный reboot-test перед production-окном
Настройка по шагам ¶
- Создайте systemd unit в `/etc/systemd/system/`, укажите рабочую директорию с compose-файлом и явный `ExecStart=/usr/bin/docker compose up -d`.
- Добавьте зависимости `After=docker.service network-online.target` и `Requires=docker.service`, чтобы unit не стартовал раньше Docker и сети.
- Оставьте restart policy внутри compose для контейнеров, а systemd используйте для поднятия всего проекта после reboot.
- Включите unit через `systemctl enable`, затем выполните `daemon-reload` и тестовый `systemctl start`.
- Проведите настоящий reboot-test и проверьте UI, webhook, worker job, queue и логи через `journalctl -u <unit>`.
Типичные ошибки ¶
- unit запускается из неправильной директории, поэтому systemd не видит compose-файл
- проверяют только `docker ps`, но не внешний webhook и не выполнение jobs через worker
- systemd стартует до network-online, из-за чего proxy или callback URL работает нестабильно
- autorestart считают заменой backup, хотя он не защищает от битой базы, env или неверного образа
Проверка ¶
- После reboot все контейнеры проекта должны быть `up` без ручного `docker compose up`.
- `journalctl -u` показывает успешный старт, а не скрытый exit с кодом ошибки.
- Внешний production webhook отвечает по HTTPS и execution появляется в n8n.
- Тестовый workflow проходит через worker, а очередь Redis не остаётся с зависшими jobs.
Мини-чеклист ¶
- есть владелец workflow
- есть тестовый пример входа
- есть error branch или error workflow
- секреты вынесены в credentials/env
Production-подход: изменение, проверка, откат ¶
Autorestart Docker n8n после reboot относится к инфраструктуре, поэтому главная ошибка — менять конфигурацию без плана отката. Перед правкой сохраните текущий compose/env, сделайте backup базы, проверьте значение N8N_ENCRYPTION_KEY и подготовьте smoke-test для UI, webhook, schedule trigger, credentials и worker.
| Этап | Что проверить | Критерий готовности |
|---|---|---|
| До изменения | backup, env, версия образа, свободный диск, логи | есть путь восстановления |
| Во время изменения | одна правка за раз, понятный owner, окно обслуживания | известно, кто принимает решение об откате |
| После изменения | UI, production webhook, manual execution, queue/worker, error workflow | нет роста failed/queued executions |
| Через сутки | размер БД, Redis, latency, rate limits внешних API | показатели стабильны, алерты молчат |
Что нельзя смешивать в одной статье ¶
Минимальные артефакты эксплуатации ¶
- таблица env-переменных с владельцем и датой последней проверки
- инструкция восстановления из backup на чистом окружении
- список критичных workflows и их внешних зависимостей
- алерт на failed executions, рост очереди, место на диске и ошибки Postgres/Redis
- журнал обновлений n8n: версия, дата, что проверяли, как откатываться
Runbook reboot-проверки для Docker n8n ¶
Autorestart полезен только тогда, когда он проверен настоящей перезагрузкой. В runbook запишите имя unit, директорию compose-проекта, команды диагностики, ожидаемые контейнеры и минимальный smoke-test. Если после reboot UI открывается, но webhooks не приходят или worker не забирает jobs, задача не закрыта: systemd поднял контейнеры, но production-сервис ещё не восстановлен.
Ключевые поля для разметки и поиска: systemd unit Docker autorestart docker compose up -d After docker.service restart policy journalctl
Проверка на production-данных ¶
- После reboot все контейнеры проекта должны быть `up` без ручного `docker compose up`.
- `journalctl -u` показывает успешный старт, а не скрытый exit с кодом ошибки.
- Внешний production webhook отвечает по HTTPS и execution появляется в n8n.
- Тестовый workflow проходит через worker, а очередь Redis не остаётся с зависшими jobs.
Практический контекст внедрения ¶
Эта страница должна отвечать на вопрос дежурного: “что делать после reboot, если n8n не поднялся”. Поэтому тексту важны не общие преимущества Docker, а конкретные сигналы: состояние unit, путь до compose, порядок network-online, статусы контейнеров, внешний HTTPS, queue и последний successful execution. Такой контент отделяет autorestart от общей инструкции по деплою.
| Слой | Что зафиксировать | Зачем |
|---|---|---|
| Вход | стабильный ID, source, payload version | позволяет повторить кейс без секретов |
| Контроль | success, skipped, retry, error branch | показывает деградацию до жалоб пользователей |
| Откат | owner, backup, rollback condition | сокращает время восстановления |
FAQ по production-внедрению ¶
Нужен ли systemd, если в compose есть restart: unless-stopped? ¶
Restart policy перезапускает контейнеры, но systemd удобен для поднятия всего compose-проекта после reboot и для понятных логов запуска.
Что проверять после reboot n8n? ¶
UI, внешний webhook, worker execution, Redis queue, Postgres connection и `journalctl` по systemd unit.
Autorestart защищает от потери данных? ¶
Нет. Он помогает поднять сервис после reboot, но backup Postgres, volumes и encryption key всё равно нужно хранить отдельно.
Связанные материалы ¶
Практический минимум перед закрытием задачи ¶
- проверьте настройки на main, worker и webhook процессах отдельно
- сохраните backup/env перед изменениями
- после правки прогоните smoke test UI, webhook, schedule и credential
- запишите rollback-команду или шаг возврата
Шаблон записи в runbook ¶
Инфраструктурные изменения в n8n опасны тем, что ошибка может проявиться не сразу: UI открывается, но webhooks или workers уже работают с другой конфигурацией. Поэтому проверять нужно не страницу входа, а полный путь execution.
Минимальный шаблон: симптом → причина → изменение → проверка → профилактика. Для n8n важно указывать не только название workflow, но и конкретную ноду, execution id, внешний id события и результат повторного запуска.
Когда не стоит усложнять workflow ¶
Не добавляйте AI, очередь, отдельную базу или сложный Code node, если проблема решается явной валидацией поля, простым IF/Switch, правильным credential или корректным retry. Чем меньше скрытой магии, тем легче поддерживать workflow через месяц.
Runbook-блок: как выполнять безопасно ¶
Материал Autorestart Docker n8n после reboot относится к эксплуатации n8n, поэтому его нельзя выполнять «на глаз». Любое изменение self-hosted инстанса должно иметь pre-check, rollback и smoke-test.
Pre-flight checklist ¶
- сделайте backup базы, workflows и переменных окружения;
- зафиксируйте текущую версию n8n, Node.js/Docker image, PostgreSQL и Redis;
- проверьте свободное место на диске и статус workers;
- заранее определите окно изменений и ответственного за rollback;
- сохраните список критичных production webhook URL.
Smoke-test после изменения ¶
- Откройте UI и проверьте login, credentials и список workflows.
- Запустите ручной workflow без внешних побочных эффектов.
- Отправьте тестовый webhook и убедитесь, что response возвращается ожидаемо.
- Проверьте queue/worker logs, если используется queue mode.
- Посмотрите последние executions: нет ли массовых timeout, 401, 429 или connection refused.
Rollback-критерии ¶
Откатывайте изменение, если UI недоступен, production webhooks возвращают 5xx, workers не забирают задачи, credentials не расшифровываются или новая версия ломает критичный workflow. Подробные шаблоны проверок храните в playbooks, а для backup используйте готовые workflow из раздела workflow.