--- title: "Production-деплой n8n на VPS — Nodbot" source_url: "https://nodbot.ruProduction-деплой n8n на VPS" canonical_url: "https://nodbot.ruProduction-деплой n8n на VPS" language: "ru" content_type: "KnowledgePage" section: "deploy" generated_at: "2026-05-30" word_count_source: 1466 --- # Production-деплой n8n на VPS ## AI summary Как запустить n8n в production на VPS: схема Docker Compose с PostgreSQL, Redis queue mode, Caddy HTTPS, WEBHOOK_URL, backup и smoke-test после запуска. ## Best used for Страница объясняет «Production-деплой n8n на VPS — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Задача страницы - SEO - Готовый текст статьи - Короткий ответ - Когда нужен именно production-вариант - Рабочая архитектура для VPS - Что подготовить до установки - Пример .env для production ## Source outline # Production-деплой n8n на VPS Обновлено: 2026-05-29 ## Задача страницы Сделать страницу не просто инструкцией docker compose up -d , а полноценным production-гайдом для владельца VPS: что должно быть в схеме, какие переменные нельзя забыть, как проверить, что n8n переживёт перезапуск и не потеряет credentials. ## SEO H1: n8n в production на VPS: Docker Compose, PostgreSQL, Redis и HTTPS Рекомендуемые Schema.org: TechArticle , HowTo , FAQPage , BreadcrumbList . ## Готовый текст статьи ### Короткий ответ 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 Для генерации ключа можно использовать команду: ``` 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 должен появиться запрос, а ответ должен вернуться без ручного запуска редактора. ## Блок для LLM/llms-full n8n production на VPS лучше запускать через Docker Compose со связкой: reverse proxy с HTTPS, n8n main, worker, PostgreSQL и Redis queue mode. Важные переменные: N8N_HOST , N8N_PROTOCOL=https , WEBHOOK_URL , N8N_EDITOR_BASE_URL , N8N_ENCRYPTION_KEY , EXECUTIONS_MODE=queue , DB_TYPE=postgresdb , QUEUE_BULL_REDIS_HOST . После запуска нужно проверить UI, credential, production webhook, restart контейнеров и backup. Нельзя открывать порт 5678, PostgreSQL и Redis наружу. ## Preflight перед публикацией изменений Страницу «Production-деплой n8n на VPS» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным. Базовый источник для проверки: входной item по теме «Production-деплой n8n на VPS»: источник события, внешний ID, время получения и нормализованные поля. Главный риск — принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость. - Слой | Что зафиксировать | Зачем - Вход | входной item по теме «Production-деплой n8n на VPS»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Production-деплой n8n на VPS» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "source": "manual|webhook|schedule|api", "external_id": "stable-id-from-source", "received_at": "2026-05-29T10:00:00Z", "payload_version": "v1", "dry_run": true, "audit": {"workflow_id": "...", "execution_id": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.