Production-деплой n8n на VPS: Docker, PostgreSQL и Redis ¶

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

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

Production-запуск n8n на VPS лучше собирать не как один контейнер с SQLite, а как связку из n8n main instance, отдельного worker, PostgreSQL, Redis и reverse proxy с HTTPS. В такой схеме UI и webhooks работают через домен, executions уходят в очередь, credentials шифруются постоянным N8N_ENCRYPTION_KEY, а данные можно восстановить из backup. Минимальный smoke-test после запуска: открыть UI, создать credential, выполнить webhook, перезапустить контейнеры и убедиться, что workflow, executions и credentials не пропали.

Когда нужен именно production-вариант ¶

Локальный запуск n8n хорош для обучения, но плохо подходит для рабочих автоматизаций. Production начинается там, где workflow принимает реальные лиды, пишет в CRM, отправляет сообщения клиентам, обновляет таблицы, использует платные AI API или хранит OAuth credentials. В этих сценариях нельзя зависеть от случайного локального файла SQLite, временного tunnel URL и ручного перезапуска контейнера.

Production-схема нужна, если выполняется хотя бы одно условие:

workflow должен работать 24/7 без открытого ноутбука;
есть внешние webhooks из Telegram, CRM, платежей, форм или сайта;
используются OAuth credentials, которые нельзя потерять после обновления;
executions бывают тяжёлыми, параллельными или долгими;
нужен понятный backup перед обновлением n8n;
доступ к редактору должен идти только через HTTPS-домен.

Рабочая архитектура для VPS ¶

Минимальная стабильная схема выглядит так:

Компонент	Роль в схеме	Что будет, если убрать
Caddy, Traefik или Nginx	Принимает HTTPS и проксирует запросы к n8n	OAuth и webhooks часто ломаются из-за неправильного внешнего URL
n8n main	Редактор, API, постановка executions в очередь	Без него нет UI и управления workflow
n8n worker	Выполняет jobs из очереди	Все executions будут выполняться в основном процессе
PostgreSQL	Основная база: workflows, credentials, executions metadata	SQLite сложнее обслуживать и масштабировать в production
Redis	Очередь для queue mode	Нельзя нормально разделить editor и worker
Volume с `.n8n`	Локальные настройки и часть runtime-данных	После пересоздания контейнера можно потерять важные файлы
Backup-скрипт	Снимок базы и важных файлов перед обновлением	Любая ошибка обновления превращается в ручное восстановление

На маленьком VPS всё это может жить на одной машине. Главное — не публиковать PostgreSQL и Redis наружу, не открывать порт 5678 в интернет и всегда заводить домен с HTTPS.

Что подготовить до установки ¶

Перед первым docker compose up -d проверьте четыре вещи.

Во-первых, домен. У домена должна быть A-запись на IP сервера. Для n8n лучше использовать отдельный поддомен, например n8n.example.ru, чтобы cookie, OAuth и webhook URL не смешивались с основным сайтом.

Во-вторых, firewall. Снаружи обычно нужны только 22/tcp для SSH, 80/tcp для выпуска сертификата и 443/tcp для HTTPS. Внутренние порты PostgreSQL, Redis и сам порт n8n должны быть доступны только внутри Docker network.

В-третьих, постоянный ключ шифрования. N8N_ENCRYPTION_KEY нужно задать до подключения первых credentials и хранить как секрет. Если ключ потерять или случайно заменить, старые credentials могут стать нечитаемыми.

В-четвёртых, план backup. Перед обновлением n8n нужно сохранять PostgreSQL dump, .env, compose-файл и данные, без которых нельзя восстановить workflow.

Пример `.env` для production ¶

Ниже не универсальный файл для копирования один в один, а список переменных, которые нужно осознанно заполнить.

Переменная	Пример	Зачем нужна
`N8N_HOST`	`n8n.example.ru`	Домен редактора без протокола
`N8N_PROTOCOL`	`https`	n8n понимает, что внешний адрес работает через HTTPS
`WEBHOOK_URL`	`https://n8n.example.ru/`	Внешний URL для production webhooks
`N8N_EDITOR_BASE_URL`	`https://n8n.example.ru/`	Базовый URL редактора и OAuth-сценариев
`N8N_ENCRYPTION_KEY`	длинная случайная строка	Шифрование credentials в базе
`EXECUTIONS_MODE`	`queue`	Включает выполнение через очередь
`DB_TYPE`	`postgresdb`	Переключает n8n с SQLite на PostgreSQL
`DB_POSTGRESDB_HOST`	`postgres`	Хост базы внутри Docker network
`QUEUE_BULL_REDIS_HOST`	`redis`	Redis для queue mode
`N8N_PROXY_HOPS`	`1`	Помогает корректно учитывать reverse proxy

Для генерации ключа можно использовать команду:

openssl rand -base64 32

Не коммитьте .env в публичный репозиторий и не отправляйте его в чат поддержки вместе с реальными токенами.

Порядок запуска ¶

Скопируйте compose-пакет на сервер.
Создайте .env из .env.example.
Заполните домен, пароль PostgreSQL, Redis-настройки и N8N_ENCRYPTION_KEY.
Проверьте финальный compose:

docker compose config

Загрузите образы:

docker compose pull

Запустите сервисы:

docker compose up -d

Посмотрите статусы и последние логи:

docker compose ps
docker compose logs --tail=100 n8n

Если reverse proxy выпустил сертификат, редактор должен открываться по адресу https://n8n.example.ru.

Smoke-test после запуска ¶

Не считайте установку успешной только потому, что открылся UI. Проведите короткий тест, который проверяет все критичные части схемы.

Создайте первого пользователя.
Создайте тестовый credential, который можно безопасно удалить.
Соберите workflow: Webhook → Set → Respond to Webhook.
Активируйте workflow и вызовите production URL через curl.
Запустите execution вручную и через webhook.
Перезапустите контейнеры:

docker compose restart

Проверьте, что workflow, credential и история executions остались на месте.
Выполните backup-скрипт и убедитесь, что архив реально создан.

Если хотя бы один шаг не прошёл, сначала исправьте инфраструктуру, а уже потом подключайте Telegram, CRM, почту и AI API.

Частые ошибки production-запуска ¶

Ошибка 1. Открыт порт 5678 наружу.
Так проще на старте, но небезопасно. Редактор должен быть доступен через reverse proxy и HTTPS, а не напрямую через http://ip:5678.

Ошибка 2. WEBHOOK_URL остался локальным.
Внешние сервисы будут отправлять события на неправильный адрес. Особенно заметно это в Telegram, OAuth и CRM webhooks.

Ошибка 3. Не задан N8N_ENCRYPTION_KEY.
n8n может сгенерировать ключ сам, но для production лучше задать постоянный ключ явно и использовать его на всех worker-инстансах.

Ошибка 4. PostgreSQL и Redis опубликованы на публичные порты.
Обычно им достаточно внутренней Docker network. Публикация наружу создаёт лишнюю поверхность атаки.

Ошибка 5. Обновление без backup.
Даже если обновления n8n обычно проходят спокойно, production-инстанс нужно обновлять как систему с ценными данными: сначала backup, потом pull, потом restart, потом smoke-test.

Минимальный план обслуживания ¶

Раз в неделю проверяйте место на диске, размер executions, статус backup и ошибки worker. Раз в месяц тестируйте восстановление backup на отдельной машине или хотя бы проверяйте, что dump базы не пустой. Перед каждым обновлением фиксируйте текущую версию n8n и сохраняйте compose-файл вместе с .env.example без секретов.

Production n8n — это не один идеальный compose-файл, а повторяемая процедура: предсказуемый запуск, понятные секреты, закрытые внутренние сервисы, регулярные backup и проверка после каждого изменения.

FAQ ¶

Можно ли запускать production n8n на SQLite?
Можно для очень маленьких личных сценариев, но для рабочей инсталляции лучше PostgreSQL. Так проще обслуживать backup, перенос и рост нагрузки.

Зачем Redis, если workflow мало?
Redis нужен для queue mode. Даже если нагрузка небольшая, разделение editor и worker делает схему устойчивее: UI не смешивается с выполнением тяжёлых задач.

Что будет, если поменять N8N_ENCRYPTION_KEY?
Credentials, зашифрованные старым ключом, могут стать недоступны. Перед любыми изменениями ключа нужен полный backup и отдельный план миграции.

Нужно ли публиковать порт PostgreSQL?
Нет, если база используется только контейнерами n8n. Оставьте PostgreSQL и Redis внутри Docker network.

Как понять, что webhook URL настроен правильно?
Создайте активный workflow с Webhook node и вызовите production URL с внешней машины. В execution должен появиться запрос, а ответ должен вернуться без ручного запуска редактора.