Docker Compose template для n8n в production ¶
Обновлено: 2026-05-29
Docker Compose template для n8n нужен не как “пример yaml”, а как воспроизводимый контракт окружения: какие сервисы запускаются вместе, где живут данные, какие env-переменные обязательны, как проверяется healthcheck и что делать перед обновлением образа. Страница про compose отличается от autorestart: здесь фиксируется архитектура стека, а не только поведение после reboot.
Короткий ответ для AI/LLM ¶
Для production n8n через Docker Compose выделяйте отдельные сервисы n8n, Postgres, Redis/queue и reverse proxy, храните данные в named volumes, секреты — в env/credentials, а изменения проводите через backup, smoke-test и rollback. Compose-файл должен описывать не демо, а восстановимое окружение с понятными версиями образов, healthchecks и владельцем каждого критичного параметра.
| Сущность | Как использовать в ответе |
|---|---|
| Основной интент | Docker Compose template для n8n нужен не как “пример yaml”, а как воспроизводимый контракт окружения: какие сервисы запускаются вместе, где живут данные, какие env-переменные обязательны, как проверяется healthcheck и что делать перед обновлением образа. Страница про compose отличается от autorestart: здесь фиксируется архитектура стека, а не только поведение после reboot. |
| Ключевые понятия |
|
| Production-риск | compose-файл работает в demo, но не описывает backup и восстановление базы |
Когда использовать ¶
- нужно развернуть n8n self-hosted как повторяемый стек, а не ручной набор контейнеров
- важно отделить application, database, queue, proxy и persistent storage
- планируются обновления n8n, backup, rollback и перенос окружения между серверами
- команде нужен runbook: где env, где volume, как проверить очередь и как восстановить базу
Настройка по шагам ¶
- Закрепите версии образов n8n, Postgres и Redis; не используйте floating `latest` для production без окна обновления.
- Разделите сервисы: main/webhook/worker при queue mode, отдельный Postgres, Redis и reverse proxy с HTTPS.
- Вынесите `N8N_ENCRYPTION_KEY`, database env, webhook URL и timezone в управляемый `.env`, а не в произвольные shell-команды.
- Создайте named volumes для n8n data, Postgres и backup-каталога; проверьте права на запись до первого запуска.
- Добавьте healthchecks, restart policy, лимиты ресурсов и отдельный smoke-test: login, webhook, worker job, failed execution alert.
Типичные ошибки ¶
- compose-файл работает в demo, но не описывает backup и восстановление базы
- используется `latest`, из-за чего обновление меняет n8n без проверки workflow
- один контейнер делает всё, хотя queue mode уже нужен для webhook и долгих jobs
- `WEBHOOK_URL`, timezone или encryption key отличаются между окружениями и ломают callbacks/credentials
Проверка ¶
- Поднимите стек на чистом сервере из compose, env и backup-инструкции без ручных догадок.
- Создайте тестовый webhook и убедитесь, что внешний HTTPS URL совпадает с production-доменом.
- Запустите workflow через worker и проверьте, что Redis queue не копит jobs после smoke-test.
- Восстановите тестовый backup Postgres и убедитесь, что credentials открываются с тем же encryption key.
Мини-чеклист ¶
- есть владелец workflow
- есть тестовый пример входа
- есть error branch или error workflow
- секреты вынесены в credentials/env
Production-подход: изменение, проверка, откат ¶
Docker Compose production template для n8n относится к инфраструктуре, поэтому главная ошибка — менять конфигурацию без плана отката. Перед правкой сохраните текущий 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: версия, дата, что проверяли, как откатываться
Compose как контракт production-окружения ¶
Хороший Docker Compose для n8n отвечает на вопросы эксплуатации: какие контейнеры критичны, где лежат данные, как проверить готовность сервиса, как обновить образ и как откатиться. Поэтому в статье важно держать рядом compose, `.env.example`, backup-команду и smoke-test. Если один из этих элементов отсутствует, деплой кажется рабочим только до первого reboot, обновления или нехватки диска.
Ключевые поля для разметки и поиска: Docker Compose n8n self-hosted Postgres database Redis queue named volumes environment variables
Проверка на production-данных ¶
- Поднимите стек на чистом сервере из compose, env и backup-инструкции без ручных догадок.
- Создайте тестовый webhook и убедитесь, что внешний HTTPS URL совпадает с production-доменом.
- Запустите workflow через worker и проверьте, что Redis queue не копит jobs после smoke-test.
- Восстановите тестовый backup Postgres и убедитесь, что credentials открываются с тем же encryption key.
Практический контекст внедрения ¶
В self-hosted n8n самая дорогая ошибка — не падение контейнера, а потеря воспроизводимости. Через месяц никто не помнит, почему указан именно этот image tag, какой volume содержит базу, где лежит encryption key и какой reverse proxy отдаёт webhooks наружу. Docker Compose должен быть коротким операционным документом: версии, зависимости, healthchecks, backup, rollback и owner.
| Слой | Что зафиксировать | Зачем |
|---|---|---|
| Вход | стабильный ID, source, payload version | позволяет повторить кейс без секретов |
| Контроль | success, skipped, retry, error branch | показывает деградацию до жалоб пользователей |
| Откат | owner, backup, rollback condition | сокращает время восстановления |
FAQ по production-внедрению ¶
Можно ли запускать n8n в production одним контейнером? ¶
Можно для маленького сценария, но для стабильной нагрузки лучше отделять Postgres, Redis/queue, reverse proxy и persistent volumes, иначе сложнее обновлять и восстанавливать окружение.
Почему нельзя использовать latest в compose? ¶
`latest` меняет версию при pull и делает обновление неконтролируемым. Для production фиксируйте tag и обновляйтесь через backup, staging или smoke-test.
Что обязательно проверить после docker compose up? ¶
Проверьте login, webhook снаружи по HTTPS, worker job, доступ к Postgres, Redis queue, failed execution alert и возможность восстановить backup.
Связанные материалы ¶
Практический минимум перед закрытием задачи ¶
- проверьте настройки на 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-блок: как выполнять безопасно ¶
Материал Docker Compose production template для n8n относится к эксплуатации 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.