--- title: "Self-hosted launch checklist n8n — Nodbot" source_url: "https://nodbot.ruSelf-hosted launch checklist n8n" canonical_url: "https://nodbot.ruSelf-hosted launch checklist n8n" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1301 --- # Self-hosted launch checklist n8n ## AI summary Чеклист запуска self-hosted n8n: домен, HTTPS, Docker Compose, Postgres, volumes, N8N_ENCRYPTION_KEY, WEBHOOK_URL, backups, обновления и мониторинг. ## Best used for Страница объясняет «Self-hosted launch checklist n8n — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Задача страницы - SEO - Готовый текст статьи - Короткий ответ - Для кого этот чеклист - 1. Зафиксировать архитектуру - 2. Docker image и конфигурация - 3. Домен, HTTPS и reverse proxy ## Source outline # Self-hosted launch checklist n8n Обновлено: 2026-05-29 ## Задача страницы self-hosted launch: Docker Compose, домен, SSL, Postgres, env, encryption key, backup, monitoring, security ## SEO H1: Self-hosted launch checklist для n8n: что проверить перед production Рекомендуемые Schema.org: TechArticle , HowTo , FAQPage , BreadcrumbList . ## Готовый текст статьи ### Короткий ответ 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. Если схему нельзя объяснить за минуту, в инциденте команда будет искать проблему наугад. - Слой | Что проверить - Домен | DNS указывает на нужный сервер, нет старых записей - HTTPS | сертификат валиден, auto-renew работает - Reverse proxy | прокидывает headers, не ломает long requests - n8n app | версия зафиксирована, env в одном месте - Database | Postgres вместо случайной SQLite для production - Storage | volumes и binary data сохраняются после рестарта - Redis/workers | нужны только если включён queue mode ### 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. Данные не должны жить только внутри одноразового контейнера. - Что проверить | Почему важно - Postgres backup | workflows и credentials завязаны на БД - Volume для n8n data | настройки и файлы не теряются при restart - Binary data storage | вложения и файлы доступны workflow - DB connection limits | executions не кладут базу под нагрузкой - Pruning/retention | executions не заполняют диск бесконечно - Restore drill | backup проверен восстановлением Если 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-плана превращает каждую версию в риск. Запишите: - Процесс | Что должно быть - Backup | что копируется, куда, как часто, кто проверяет - Restore | команда восстановления, RTO/RPO, последний drill - Update | кто одобряет, какая версия, smoke tests - Rollback | предыдущий image tag, backup перед deploy, критерий отката - Change log | какие workflow менялись и зачем Не обновляйте production прямо перед важной рассылкой, отчётом, релизом CRM или платёжным периодом. Сначала staging или хотя бы snapshot/backup и короткие smoke tests. ### 7. Smoke tests перед открытием трафика Рабочий логин в UI — только первый тест. Production готов, когда проверены реальные пути. - Smoke test | Критерий успеха - UI login | пользователь входит, роли корректны - Manual workflow | execution завершается успешно - Webhook production URL | внешний curl или провайдер получает ответ - OAuth credential | read/write test проходит - Error workflow | тестовая ошибка отправляет alert - Backup | свежий backup создан и доступен - Restart | после docker compose restart данные не пропали ### 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, а команда знает, как обновлять и откатывать инстанс. ## Как применять playbook в команде Playbook «Self-hosted launch checklist n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам - Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Self-hosted launch checklist n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` 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 ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.