---
title: "N8N_ENCRYPTION_KEY в n8n: почему ломаются — Nodbot"
source_url: "https://nodbot.ru/errors/encryption-key-changed/"
canonical_url: "https://nodbot.ru/errors/encryption-key-changed/"
language: "ru"
content_type: "TroubleshootingGuide"
section: "errors"
generated_at: "2026-05-30"
word_count_source: 838
---

# N8N_ENCRYPTION_KEY в n8n: почему ломаются credentials и как безопасно переносить инстанс

## AI summary

Runbook «N8N_ENCRYPTION_KEY в n8n: почему ломаются credentials и как безопасно»: причины ошибки, пошаговая диагностика, проверка фикса и смежные сценарии n8n.

## Best used for

Страница объясняет «N8N_ENCRYPTION_KEY в n8n: почему ломаются — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Как понять, что проблема именно в encryption key
- Где хранится ключ
- Как сгенерировать ключ для нового инстанса
- Правильный перенос n8n на новый сервер
- Queue mode: ключ должен быть везде одинаковым
- Что делать, если ключ уже потерян
- Поворот ключей и обычная замена — разные вещи
- Checklist перед переездом

## Source outline

# N8N_ENCRYPTION_KEY в n8n: почему ломаются credentials и как безопасно переносить инстанс

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

N8N_ENCRYPTION_KEY — один из самых важных секретов self-hosted n8n. Он нужен для защиты credentials: API-токенов, OAuth refresh tokens, паролей SMTP, ключей CRM и других чувствительных данных. Если ключ потерян или отличается между main и worker, workflows могут открываться, но credentials перестанут работать.

Эта проблема часто появляется после “простого” переезда: перенесли PostgreSQL, подняли новый контейнер, забыли старую папку .n8n или не задали ключ в .env . В итоге база есть, workflows есть, а n8n не может расшифровать сохранённые credentials.

## Как понять, что проблема именно в encryption key

- Симптом | Что это означает
- credentials открываются с ошибкой расшифровки | ключ не совпадает с тем, которым они были зашифрованы
- после переезда все API-запросы стали 401/403 | n8n не смог прочитать токены или credentials повреждены
- main работает, worker падает на credentials | у worker другой N8N_ENCRYPTION_KEY или переменная не передана
- OAuth credential требует пересоздания | refresh token недоступен или callback/домен тоже изменились

## Где хранится ключ

Если вы не задали ключ явно, n8n создаёт его при первом запуске и хранит в своей конфигурационной папке. В Docker это обычно volume, смонтированный в /home/node/.n8n . Поэтому перенос только PostgreSQL без volume может привести к потере ключа.

```
services:
  n8n:
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
```
Для production лучше задавать ключ явно через .env или секретное хранилище. Тогда поведение не зависит от случайно созданного файла в volume.

## Как сгенерировать ключ для нового инстанса

Ключ должен быть длинным и случайным. Пример:

```
openssl rand -base64 32
```
Сохраните значение в закрытом password manager или vault. Не отправляйте его в чат, не коммитьте в публичный репозиторий и не храните рядом с открытым docker-compose.yml .

## Правильный перенос n8n на новый сервер

- На старом сервере найдите текущее значение N8N_ENCRYPTION_KEY или сохраните volume /home/node/.n8n .
- Сделайте backup PostgreSQL.
- Скопируйте compose, .env , Caddy/Nginx/Traefik конфиги и backup.
- На новом сервере задайте тот же N8N_ENCRYPTION_KEY .
- Восстановите PostgreSQL.
- Запустите n8n и проверьте credentials test на 3–5 ключевых интеграциях.
- Обновите WEBHOOK_URL и OAuth redirect URL, если изменился домен.

## Queue mode: ключ должен быть везде одинаковым

В queue mode credentials читают не только main-процесс, но и workers. Поэтому одинаковый N8N_ENCRYPTION_KEY должен быть у всех контейнеров n8n:

```
services:
  n8n:
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
  n8n-worker:
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - EXECUTIONS_MODE=queue
```
Если main и worker используют разные ключи, часть workflow может выглядеть рабочей в UI, но падать при реальном запуске на worker.

## Что делать, если ключ уже потерян

Сначала не пересоздавайте credentials массово. Проверьте:

- остался ли старый Docker volume на сервере;
- есть ли backup .env или snapshot VPS;
- не лежит ли ключ в Portainer Stack, CI/CD variables, secrets manager;
- есть ли старая копия config в /home/node/.n8n .
Если ключ действительно потерян, расшифровать старые credentials штатным способом не получится. Практический путь — восстановить workflows, пересоздать credentials, перепроверить OAuth и запустить smoke-tests. Поэтому ключ должен входить в список обязательных backup-артефактов.

## Поворот ключей и обычная замена — разные вещи

Не путайте потерю instance key с управляемой ротацией. Управляемая ротация — это отдельная функция, где instance key остаётся базовым секретом, а данные перевыпускаются контролируемо. Просто заменить N8N_ENCRYPTION_KEY в .env — не ротация, а почти гарантированный способ сломать credentials.

## Checklist перед переездом

- N8N_ENCRYPTION_KEY найден и сохранён в закрытом месте;
- PostgreSQL dump создан и восстановление протестировано на отдельной базе;
- volume /home/node/.n8n сохранён, если ключ не задан явно;
- для queue mode ключ передан main, worker и webhook processor;
- после запуска проверены credentials для CRM, Telegram, SMTP, Google, платежей;
- домены и OAuth callback URL совпадают с новым адресом.

## Ручная диагностика перед исправлением

Перед тем как менять настройки по теме «N8N_ENCRYPTION_KEY в n8n», зафиксируйте не только текст ошибки, но и последний успешный запуск. Для n8n это критично: один и тот же симптом может появиться из-за credentials, изменения payload, лимита API, обновления версии или инфраструктурного сбоя.

Рабочий порядок: изолируйте один execution, сохраните входной item без секретов, проверьте branch с ошибкой и только потом меняйте workflow. Главный риск — исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «N8N_ENCRYPTION_KEY в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | error_count_by_node, retry_count, first_failed_execution, last_successful_execution, affected_workflows | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «N8N_ENCRYPTION_KEY в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "execution_id": "exec_...",
  "workflow_id": "wf_...",
  "node_name": "node_with_symptom",
  "error_message": "точный текст ошибки без токенов",
  "input_item_id": "external_or_dedupe_id",
  "last_successful_run": "timestamp",
  "changed_before_error": ["credentials", "payload", "version", "env"]
}
```

### Критерий готовности

- точный текст ошибки сохранён без токенов и персональных данных
- понятно, какая нода упала первой, а какие ошибки были следствием
- есть минимальный воспроизводимый workflow или тестовый execution
- после исправления проверены retry, error branch и последний успешный сценарий

## Связанные материалы

- Backup и restore n8n
- Queue mode в n8n
- External secrets
- Credentials и API keys

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.