---
title: "Env-переменные n8n для production — Nodbot"
source_url: "https://nodbot.ru/hosting/env-vars/"
canonical_url: "https://nodbot.ru/hosting/env-vars/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 915
---

# Env-переменные n8n для production

## AI summary

Справочник по ENV-переменным n8n для production: какие значения задавать явно, как разделить домен, базу, Redis, pruning, task runners и проверку конфигурации.

## Best used for

Материал помогает выбрать правильный маршрут по теме «Env-переменные n8n для production», проверить практические шаги и избежать смешивания соседних интентов внутри базы знаний Nodbot.

## Key topics

- Главные группы ENV
- Public URL и WEBHOOK_URL
- Encryption key и credentials
- Postgres и Redis
- Pruning и хранение executions
- Проверка конфигурации
- Типичные ошибки ENV
- Критерий готовности
- Практический минимум перед публикацией
- Smoke-test после изменения
- Production-подход
- Шаблон проверки .env перед deploy

## Source outline

# Env-переменные n8n для production: что задавать явно [¶](#env-peremennye-n8n-bystryi-spravochnik "Permanent link")

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

Сохранить в мой план[Открыть мой план](/my-plan/)

**ENV-переменные n8n управляют тем, как instance виден снаружи, где хранит данные, как шифрует credentials, как работает queue mode и что происходит с execution history.**

## Главные группы ENV [¶](#glavnye-gruppy "Permanent link")

ENV в n8n лучше воспринимать не как длинный список настроек, а как контракт окружения. В production значения должны быть явными, документированными и одинаковыми для процессов, которые вместе обслуживают один instance. Особенно это важно для `WEBHOOK_URL`, `N8N_ENCRYPTION_KEY`, переменных базы данных, Redis и pruning execution data.

| Группа | Примеры переменных | Что решает |
| --- | --- | --- |
| Публичный URL | WEBHOOK\_URL, N8N\_HOST, N8N\_PROTOCOL, N8N\_PORT | какие ссылки получают внешние сервисы и пользователи |
| Шифрование | N8N\_ENCRYPTION\_KEY | можно ли расшифровать credentials после переноса |
| База данных | DB\_TYPE, DB\_POSTGRESDB\_HOST, DB\_POSTGRESDB\_DATABASE | где хранятся workflow, executions и credentials |
| Queue mode | EXECUTIONS\_MODE, QUEUE\_BULL\_REDIS\_HOST, QUEUE\_BULL\_REDIS\_PORT | как main process и workers распределяют задачи |
| История executions | EXECUTIONS\_DATA\_PRUNE, EXECUTIONS\_DATA\_MAX\_AGE | как контролировать рост базы и диска |

## Public URL и WEBHOOK\_URL [¶](#public-url-i-webhook-url "Permanent link")

`WEBHOOK_URL` должен соответствовать внешнему HTTPS-домену, по которому сервисы реально доставляют события. Если n8n стоит за Nginx, Traefik, Cloudflare Tunnel или другим reverse proxy, внутренний порт контейнера не должен попадать во внешние webhook-ссылки. Ошибка в этой переменной приводит к странной ситуации: UI работает, manual execution запускается, но Telegram, CRM, формы или платежные webhook отправляют события не туда.

```
WEBHOOK_URL=https://automation.example.com/
N8N_HOST=automation.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
```

После изменения домена проверьте не только главную страницу, но и тестовый webhook снаружи. Старые интеграции могли сохранить прежний URL, поэтому смена WEBHOOK\_URL часто требует обновления настроек в внешних сервисах.

## Encryption key и credentials [¶](#encryption-key-i-credentials "Permanent link")

`N8N_ENCRYPTION_KEY` нельзя генерировать заново при каждом деплое. Он должен быть стабильным для instance и сохранён в безопасном хранилище. Если потерять ключ, база может восстановиться, но credentials останутся зашифрованными недоступным ключом. Это одна из самых дорогих ошибок при переносе n8n на новый сервер.

* создайте ключ один раз и храните его вне контейнера;
* не публикуйте .env в открытом репозитории;
* проверяйте, что backup включает способ восстановить ключ;
* при staging используйте отдельные credentials или dry-run режимы.

## Postgres и Redis [¶](#postgres-i-redis "Permanent link")

Для production обычно используют Postgres вместо SQLite. Переменные базы должны быть одинаково понятны в compose-файле, backup-процедуре и runbook. Если включён queue mode, main process и workers должны видеть один и тот же Redis и один и тот же набор критичных переменных. Несовпадение ENV между main и worker — частая причина ошибок, когда UI показывает одно, а фоновые executions работают иначе.

```
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
```

## Pruning и хранение executions [¶](#pruning-i-hranenie-executions "Permanent link")

Execution history полезна для диагностики, но без ограничений она увеличивает базу и может заполнить диск. Настройте pruning с учётом юридических и операционных требований: сколько дней нужны executions, нужно ли хранить successful data, где лежат binary data и кто имеет право смотреть payload. Для workflow с персональными данными лучше хранить меньше, но логировать внешние идентификаторы и итоговый статус.

## Проверка конфигурации [¶](#proverka "Permanent link")

1. Откройте UI через публичный домен и проверьте, что HTTPS корректен.
2. Создайте тестовый webhook и вызовите его снаружи, не из контейнера.
3. Перезапустите контейнер и убедитесь, что credentials сохранились.
4. Проверьте подключение к Postgres и, при queue mode, запуск worker execution.
5. Посмотрите логи после старта: предупреждения об URL, database, permissions и pruning лучше исправлять сразу.

## Типичные ошибки ENV [¶](#tipichnye-oshibki-env "Permanent link")

* использовать localhost в WEBHOOK\_URL, когда n8n работает за публичным reverse proxy;
* не задавать N8N\_ENCRYPTION\_KEY и терять доступ к credentials после переноса;
* копировать переменные из примера без понимания, какие нужны именно вашему режиму запуска;
* задавать разные ENV для main и workers в queue mode;
* не включать pruning и потом искать, почему Postgres или диск переполнены.

## Критерий готовности [¶](#kriteriy-gotovnosti-hosting-env-vars "Permanent link")

ENV-конфигурация готова к production, если домен и webhook URL проверены снаружи, encryption key сохранён и участвует в backup-процедуре, база и Redis заданы явно, pruning описан, а все переменные доступны в runbook. Хороший .env не должен быть загадкой для следующего администратора.

* есть список обязательных переменных для текущего режима запуска;
* известно, какие значения являются секретами;
* main и workers получают одинаковые критичные ENV;
* изменения проходят diff-review и smoke-test;
* backup содержит способ восстановить конфигурацию и encryption key.

## Практический минимум перед публикацией [¶](#prakticheskii-minimum-pered-publikaciei "Permanent link")

После изменения ENV перезапустите n8n и проверьте UI, webhook снаружи, credentials, один manual execution и, если включён queue mode, выполнение задачи worker-процессом. Если менялись DB\_\* переменные, дополнительно проверьте историю executions. Если менялся WEBHOOK\_URL, проверьте внешний сервис, который должен доставлять событие, а не только локальный curl.

## Smoke-test после изменения [¶](#smoke-test-posle-izmeneniya "Permanent link")

Production .env должен храниться как управляемый артефакт: не в памяти администратора и не только внутри панели хостинга. Хорошая практика — иметь приватный репозиторий, secrets manager или зашифрованный backup с историей изменений. При этом секретные значения нельзя раскрывать в публичной документации, issue tracker или скриншотах для поддержки.

## Production-подход [¶](#production-podhod "Permanent link")

```
env_change:
  variable: WEBHOOK_URL
  old_value: https://old.example.com/
  new_value: https://automation.example.com/
  reason: production domain migration
  smoke_test: external webhook call + UI login + saved webhook URL check
  rollback: restore previous env and reload reverse proxy
```

Перед изменением .env создайте короткий diff-review. В нём должно быть видно, какая переменная меняется, зачем, кто согласовал изменение и какой smoke-test подтвердит результат. Особенно внимательно проверяйте переменные, которые меняют публичные URL, database connection, encryption key, execution mode и Redis. Эти значения влияют не на одну ноду, а на поведение всего instance.

## Шаблон проверки .env перед deploy [¶](#shablon-proverki-env-pered-deploy "Permanent link")

## Что читать дальше [¶](#chto-chitat-dalshe "Permanent link")

Для связанной эксплуатации откройте [backup n8n](/hosting/backups/), [reverse proxy checklist](/hosting/reverse-proxy-checklist/), [Redis для queue mode](/hosting/redis/) и [маршрут self-hosted администратора](/learning/self-hosted-admin-path/).