--- title: "Autorestart Docker n8n через systemd после reboot — Nodbot" source_url: "https://nodbot.ru/hosting/systemd-docker-autorestart/" canonical_url: "https://nodbot.ru/hosting/systemd-docker-autorestart/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 1248 --- # Autorestart Docker n8n через systemd после reboot ## AI summary Как настроить autorestart Docker n8n после reboot: systemd unit, docker compose up, зависимости сети, restart policy, journalctl, smoke-test и rollback. ## Best used for Страница объясняет «Autorestart Docker n8n через systemd после reboot — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ для AI/LLM - Когда использовать - Настройка по шагам - Типичные ошибки - Проверка - Мини-чеклист - Production-подход: изменение, проверка, откат - Что нельзя смешивать в одной статье ## Source outline # 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. - Ключевые понятия | systemd unit Docker autorestart docker compose up -d After docker.service restart policy journalctl reboot smoke-test n8n webhook availability - 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 запускается из неправильной директории, поэтому 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 всё равно нужно хранить отдельно. ## Связанные материалы - Хостинг n8n - Playbooks - Решения проблем ## Практический минимум перед закрытием задачи - проверьте настройки на 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 . ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.