Безопасность n8n self-hosted: HTTPS, доступы и секреты ¶

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

Self-hosted n8n часто имеет доступ к CRM, почте, таблицам, Telegram, базам и AI-сервисам. Один открытый editor или утёкший token может дать доступ ко всей автоматизации бизнеса, поэтому безопасность — часть архитектуры.

HTTPS и доступ ¶

Публичный n8n должен работать по HTTPS. Ограничьте доступ к editor: пользователи, сильные пароли, минимальные права, а при необходимости VPN, IP allowlist или proxy-auth.

Credentials и секреты ¶

Не храните токены в workflow, Code node, комментариях и публичных exports. Используйте credentials. Сохраните N8N_ENCRYPTION_KEY в безопасном месте, иначе восстановление credentials может стать проблемой.

Сервер ¶

Включите firewall, оставьте только нужные порты, обновляйте систему и Docker images. Не запускайте лишние сервисы на том же VPS. Логи не должны содержать секреты и полные payload с чувствительными данными.

Webhook-безопасность ¶

Не доверяйте payload только потому, что он пришёл на секретный URL. Для критичных действий добавляйте подпись, shared secret, проверку источника или ручное подтверждение. Особенно осторожно подключайте AI Agent к инструментам, меняющим данные.

Production-подход: изменение, проверка, откат ¶

Безопасность n8n self-hosted: HTTPS, доступы и секреты относится к инфраструктуре, поэтому главная ошибка — менять конфигурацию без плана отката. Перед правкой сохраните текущий compose/env, сделайте backup базы, проверьте значение N8N_ENCRYPTION_KEY и подготовьте smoke-test для UI, webhook, schedule trigger, credentials и worker.

Что нельзя смешивать в одной статье ¶

Минимальные артефакты эксплуатации ¶

• таблица env-переменных с владельцем и датой последней проверки
• инструкция восстановления из backup на чистом окружении
• список критичных workflows и их внешних зависимостей
• алерт на failed executions, рост очереди, место на диске и ошибки Postgres/Redis
• журнал обновлений n8n: версия, дата, что проверяли, как откатываться

Runbook-блок: как выполнять безопасно

Материал Безопасность n8n self-hosted: HTTPS, доступы и секреты относится к эксплуатации 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 после изменения

1. Откройте UI и проверьте login, credentials и список workflows.
2. Запустите ручной workflow без внешних побочных эффектов.
3. Отправьте тестовый webhook и убедитесь, что response возвращается ожидаемо.
4. Проверьте queue/worker logs, если используется queue mode.
5. Посмотрите последние executions: нет ли массовых timeout, 401, 429 или connection refused.

Rollback-критерии

Откатывайте изменение, если UI недоступен, production webhooks возвращают 5xx, workers не забирают задачи, credentials не расшифровываются или новая версия ломает критичный workflow. Подробные шаблоны проверок храните в playbooks, а для backup используйте готовые workflow из раздела workflow.

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

Что читать дальше ¶

Связанные темы: Credentials, WEBHOOK_URL, backup/update.

Чеклист production ¶

Перед использованием self-hosted n8n в боевых процессах проверьте не только запуск контейнера, но и восстановление. Установка считается готовой, когда вы знаете, где лежит база, как восстановить credentials, какие env отвечают за публичный домен и кто получает уведомление при сбое.

• Домен работает по HTTPS, а production webhook открывается извне.
• PostgreSQL и volumes бэкапятся по расписанию.
• N8N_ENCRYPTION_KEY сохранён вне сервера.
• Доступ к editor ограничен пользователями, сетью или proxy.
• После обновления проверяются webhook, OAuth и критичные workflow.

Типичный риск ¶

Главная ошибка self-hosted установки — считать, что если UI открылся, инфраструктура готова. Для n8n важны публичные callback URL, сохранность базы, секреты, timezone расписаний и процедура rollback. Эти вещи лучше проверить до первого критичного workflow.