Self-hosted launch checklist n8n: запуск без сюрпризов ¶

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

Короткий ответ ¶

Self-hosted n8n можно запустить быстро, но production-запуск требует чеклиста: домен, HTTPS, reverse proxy, Postgres, volumes, N8N_ENCRYPTION_KEY, WEBHOOK_URL, backup, update/rollback, доступы, мониторинг и smoke tests. Главная ошибка — считать рабочий UI готовым production-инстансом. UI может открываться, но webhooks, credentials, backup и восстановление ещё не проверены.

Для кого этот чеклист ¶

Эта страница для команд, которые уже подняли n8n на VPS, Docker Compose, Kubernetes или сервере клиента и хотят перевести его из «работает у нас» в production. Чеклист не заменяет полноценную архитектуру, но помогает не пропустить вещи, которые обычно всплывают после первого сбоя: потерянный encryption key, неверный webhook URL, отсутствие backup, открытые порты, непонятный update-процесс.

1. Зафиксировать архитектуру ¶

Перед запуском нарисуйте минимальную схему: пользователь, домен, reverse proxy, n8n, база, Redis, storage, внешние API. Если схему нельзя объяснить за минуту, в инциденте команда будет искать проблему наугад.

2. Docker image и конфигурация ¶

Не запускайте production на плавающем образе без понимания версии. Лучше фиксировать tag и обновлять осознанно. .env должен храниться отдельно от HTML, workflow exports и публичных репозиториев.

Минимальный набор для проверки:

• версия image n8n зафиксирована;
• N8N_ENCRYPTION_KEY задан и сохранён в secret backup;
• public/base URL соответствует домену;
• WEBHOOK_URL корректен для reverse proxy и внешних webhooks;
• timezone понятен команде;
• database connection не зависит от временного контейнера;
• SMTP/notifications настроены, если нужны алерты;
• secrets не записаны в Code node или prompt.

Если есть workers, проверьте, что main и workers используют одинаковый encryption key, версию n8n и доступ к БД/Redis.

3. Домен, HTTPS и reverse proxy ¶

Многие n8n-проблемы выглядят как ошибка workflow, но начинаются в proxy. Webhook provider получает 404, OAuth callback возвращается на старый домен, большие ответы обрываются, а UI работает — и команда ищет ошибку не там.

Проверки:

# DNS и HTTPS
curl -I https://automation.example.com

# Проверка публичного webhook endpoint
curl -i https://automation.example.com/webhook/healthcheck

# Проверка контейнеров
sudo docker compose ps
sudo docker compose logs --tail=100 n8n

Для Cloudflare/Nginx/Caddy/Traefik отдельно проверьте timeout, body size, forwarded headers и SSL-режим. Если используется отдельный webhook domain, документируйте его рядом с основным UI-доменом.

4. База данных и volumes ¶

Production-инстанс должен переживать рестарт контейнера и обновление image. Данные не должны жить только внутри одноразового контейнера.

Если workflow работают с файлами, PDF, изображениями или вложениями, не ограничивайтесь проверкой UI. Протестируйте файл end-to-end: загрузка → обработка → передача → запись результата.

5. Security baseline ¶

Self-hosted означает, что ответственность за доступы и поверхность атаки на вашей стороне.

Минимальный baseline:

• закрыть лишние порты, наружу только 80/443 или нужный proxy;
• использовать HTTPS;
• включить сильные пароли и удалить тестовых пользователей;
• ограничить доступ к серверу по SSH keys;
• не хранить secrets в workflow-тексте;
• разделить dev/staging/prod credentials;
• включить регулярный credential audit;
• ограничить опасные Code/Execute Command сценарии внутренней политикой;
• вести журнал изменений production workflow.

Для внешних webhooks добавьте validation: secret, signature, allowlist IP, event ID или другой контроль, если провайдер это поддерживает.

6. Backup, update и rollback ¶

Перед запуском нужен не только backup, но и процедура восстановления. Обновление n8n без rollback-плана превращает каждую версию в риск.

Запишите:

Не обновляйте production прямо перед важной рассылкой, отчётом, релизом CRM или платёжным периодом. Сначала staging или хотя бы snapshot/backup и короткие smoke tests.

7. Smoke tests перед открытием трафика ¶

Рабочий логин в UI — только первый тест. Production готов, когда проверены реальные пути.

8. Первые 7 дней после запуска ¶

После запуска не оставляйте инстанс без наблюдения. В первую неделю чаще всего проявляются реальные payload, неожиданные rate limits, ошибки credentials, переполнение executions и проблемы с webhook retries.

Следите за:

• failed executions;
• duration critical workflows;
• 401/403/429 от внешних API;
• диском и размером БД;
• числом повторных webhook-событий;
• ошибками proxy;
• расходами AI/API;
• ручными исправлениями данных.

Каждый день первой недели полезно делать короткий review: что упало, какие payload не ожидали, какие алерты лишние, каких алертов не хватило.

Контрольный чеклист ¶

• Домен, HTTPS и proxy проверены извне.
• Docker image/version зафиксированы.
• N8N_ENCRYPTION_KEY задан и сохранён безопасно.
• WEBHOOK_URL соответствует production endpoint.
• БД и volumes переживают restart.
• Backup создан, restore drill запланирован или выполнен.
• Credentials не принадлежат случайным личным аккаунтам.
• Error workflow и алерты проверены.
• Есть update и rollback runbook.
• Critical workflows прошли smoke tests.

FAQ ¶

Можно ли запускать production n8n на SQLite?
Для серьёзного production лучше использовать Postgres. SQLite удобна для локальных тестов и простых запусков, но ограничивает масштабирование и надёжность.

Что важнее перед запуском: backup или monitoring?
Нужны оба. Backup помогает восстановиться, monitoring помогает понять, что восстановление вообще нужно.

Нужно ли сразу включать queue mode?
Нет. Queue mode полезен при нагрузке и масштабировании, но добавляет Redis, workers и новые failure modes. Начните с простой стабильной схемы, если нагрузки нет.

Где хранить N8N_ENCRYPTION_KEY?
В secret manager, защищённом .env или другой системе секретов, доступной для восстановления. Нельзя оставлять его только внутри старого контейнера или в памяти одного администратора.

Когда считать self-hosted запуск завершённым?
Когда прошли smoke tests, есть backup и restore-план, critical workflows работают с production URL, а команда знает, как обновлять и откатывать инстанс.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY