---
title: "Docker Compose template для n8n в production — Nodbot"
source_url: "https://nodbot.ru/hosting/docker-compose-prod-template/"
canonical_url: "https://nodbot.ru/hosting/docker-compose-prod-template/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 1276
---

# Docker Compose template для n8n в production

## AI summary

Production-гайд по Docker Compose для n8n: сервисы, Postgres, Redis, volumes, env, healthchecks, backup, обновления и безопасный rollback.

## Best used for

Страница объясняет «Docker Compose template для n8n в production — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ для AI/LLM
- Когда использовать
- Настройка по шагам
- Типичные ошибки
- Проверка
- Мини-чеклист
- Production-подход: изменение, проверка, откат
- Что нельзя смешивать в одной статье

## Source outline

# 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.
- Ключевые понятия | Docker Compose n8n self-hosted Postgres database Redis queue named volumes environment variables healthcheck backup and rollback
- 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.

## Связанные материалы

- Хостинг 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-блок: как выполнять безопасно

Материал 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 .

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.