n8n Docker Compose для self-hosted установки

Обновлено: 2026-05-29

Docker Compose — самый удобный формат для постоянного self-hosted n8n. Он фиксирует состав сервиса в файлах: n8n, база данных, reverse proxy, Redis/workers при необходимости, volumes, env-переменные и скрипты обслуживания.

Главная цель такой установки — не просто “открыть интерфейс n8n”, а получить предсказуемый сервер: webhook стабильно доступны снаружи, credentials не теряются, база бэкапится, обновления можно откатить, а логи помогают понять причину ошибки.

Минимальная рабочая архитектура

Как должен выглядеть compose-проект

Держите проект в отдельной директории, например /opt/n8n. Внутри должны быть минимум docker-compose.yml, .env, директория для backup и README для администратора. Не храните реальные токены в репозитории.

/opt/n8n/
  docker-compose.yml
  .env
  Caddyfile
  backups/
  scripts/
    backup.sh
    update.sh
    healthcheck.sh

Критичные env-переменные

• N8N_ENCRYPTION_KEY — фиксируется один раз и хранится вместе с backup. Это не “настройка для красоты”, а ключ к credentials.
• WEBHOOK_URL — должен указывать на публичный HTTPS-домен, например https://n8n.example.ru/.
• N8N_PROXY_HOPS — нужен за reverse proxy, чтобы n8n корректно работал с forwarded headers.
• DB_TYPE=postgresdb и параметры PostgreSQL — для production-хранения.
• GENERIC_TIMEZONE и TZ — чтобы расписания, логи и executions не расходились по времени.

Webhook за reverse proxy

Самая частая ошибка self-hosted установки — интерфейс открывается, но внешние сервисы не могут вызвать webhook. Причина обычно в неправильном домене, HTTP вместо HTTPS, неактивном workflow или неверном WEBHOOK_URL.

curl -i https://n8n.example.ru/webhook/health-test

Проверяйте webhook не с сервера, а с внешней машины. Если Telegram, ЮKassa или amoCRM видят другой URL, проблема не в workflow, а в сетевой части.

PostgreSQL и backup

Backup должен быть проверяемым. Недостаточно создать файл дампа: раз в месяц поднимайте тестовую директорию, разворачивайте PostgreSQL из backup и открывайте n8n с копией данных. Только так понятно, что восстановление реально работает.

docker compose exec -T postgres pg_dump -U n8n n8n > backups/n8n-$(date +%F).sql

Credentials зависят не только от базы, но и от N8N_ENCRYPTION_KEY. Если база восстановлена, а ключ другой, доступы могут оказаться нечитаемыми.

Когда включать Redis и workers

Queue mode нужен не всем. Его стоит рассматривать, если workflow долго работают, есть AI-запросы, много webhook, тяжёлый парсинг, отправка файлов или риск, что один долгий запуск заблокирует интерфейс и короткие задачи.

Практический признак: если вы уже обсуждаете “почему execution висит”, “как не терять webhook при нагрузке” и “как запускать несколько workers”, пора читать раздел про queue mode. Если у вас 20 запусков в день, сначала сделайте нормальный backup и monitoring.

Безопасное обновление

1. Сохраните текущую версию образа и compose-файл.
2. Сделайте backup PostgreSQL и проверьте наличие N8N_ENCRYPTION_KEY.
3. Прочитайте release notes для вашей ветки n8n.
4. Обновите staging или копию, если есть критичные workflow.
5. После обновления прогоните smoke-test: UI, login, один webhook, один cron, один workflow с credential.

Безопасность без паранойи

• Не открывайте порт 5678 напрямую наружу, используйте reverse proxy и HTTPS.
• Ограничьте SSH, обновляйте сервер, храните секреты в .env вне публичного репозитория.
• Не ставьте community nodes без понимания, кто их поддерживает и какие права они получают.
• Очищайте старые execution data, особенно если в payload есть персональные данные.
• Для опасных действий — платежи, массовые рассылки, изменения CRM — добавляйте ручное подтверждение.

Готовый пакет

Если нужен стартовый набор файлов, используйте production deployment kit. Для проблем с внешними вызовами откройте диагностику webhook, а для обновлений — инструкцию по обновлению n8n.

Ответы на частые вопросы

Можно ли оставить SQLite?

Для локальных тестов можно. Для production лучше PostgreSQL: он предсказуемее для backup, восстановления и роста объёма execution data.

Что будет, если потерять N8N_ENCRYPTION_KEY?

Workflow останутся, но credentials могут стать недоступными. Ключ нужно хранить вместе с backup и не генерировать заново при переезде.

Нужен ли Kubernetes?

Большинству проектов — нет. VPS + Docker Compose проще поддерживать. Kubernetes имеет смысл, если у команды уже есть k8s-инфраструктура и понятная эксплуатация.