Робочі процеси, що переживуть наступний перезапуск.

Захистіть редактор

Розмістіть редактор за HTTPS та підтримуваною автентифікацією. Обмежте адміністративний доступ і уникайте публічної реєстрації, коли це не потрібно. Маршрути вебхуків потребують власних рішень щодо експозиції та автентифікації.

Збережіть ключ облікових даних

Створіть резервну копію налаштованого ключа шифрування з належним захистом. Відновлення бази даних без правильного ключа може зробити збережені облікові дані непридатними. Тримайте ключ поза скриншотами, репозиторіями та невідфільтрованими журналами.

Масштабуйте шлях виконання продумано

Для навантаженого налаштування перегляньте підтримувану базу даних, чергу та модель працівників. Redis і окремі працівники додають власні вимоги до доступу та збереження. Обмежуйте одночасні завдання, щоб сплеск не вичерпав VPS або зовнішній бюджет API.

Зберігайте лише корисні дані виконання

Робочі процеси можуть обробляти токени, персональні записи та документи. Налаштуйте очищення історії виконання, редагуйте чутливі значення та ретельно визначайте повторні спроби. Дубльований вебхук не повинен спричиняти ненавмисний другий платіж або повідомлення.

Ставтеся до ключа шифрування як до частини бази даних

Збережені облікові дані залежать від ключа шифрування n8n. Зберігайте каталог стану, що містить автоматично згенерований ключ, або задайте N8N_ENCRYPTION_KEY із приватного сховища секретів. Усі воркери черги потребують того самого ключа, що й головний процес. Перевірте відновлення на одноразових облікових даних; відновлена база даних сама по собі може виглядати справною, тоді як її облікові дані залишаться нечитабельними.

• Тримайте ключ поза публічним каталогом і репозиторієм
• Регулярно створюйте резервні копії бази даних
• Використовуйте підтримуваний PostgreSQL для запланованого розгортання в робочому середовищі

Офіційна документація: конфігурація ключа шифрування n8n

Надайте вебхукам їхню публічну адресу

Зворотний проксі, наприклад Caddy, може завершувати HTTPS, тоді як n8n слухає внутрішньо. Поточна документація використовує N8N_WEBHOOK_URL для зовнішнього походження webhook і замінює старішу назву WEBHOOK_URL з версії 2.35.0. Встановіть кількість довірених переходів проксі відповідно до реального шляху; один проксі використовує N8N_PROXY_HOPS=1. Зберігайте передані хост, протокол та інформацію про клієнта. Перевірте webhook ззовні сервера та переконайтеся в його робочому URL.

• Свідомо встановіть часовий пояс робочого процесу
• Видаляйте історію виконань, що містить чутливі вхідні дані
• Використовуйте обробники черг і Redis лише з необхідними засобами контролю приватного доступу

# Example: one HTTPS reverse proxy
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1

Офіційна документація: n8n за зворотним проксі

Визначте робоче навантаження та дозволені інтеграції

Перелічіть тригери, зовнішні облікові записи, очікуваний обсяг виконання та максимальні витрати або побічний ефект, який може створити кожен робочий процес. Перевірте ліцензію n8n для фактичного використання, особливо якщо пропонуєте його як послугу іншим. Невеликий запланований робочий процес і обробник публічних вебхуків мають різні потреби в ресурсах. Почніть із підтримуваного випуску, приватного постійного стану, імені TLS та бази даних, що відповідає розгортанню; уникайте відкриття портів бази даних разом із редактором.

• Використовуйте окремі обмежені облікові дані для кожної інтеграції.
• Встановіть часовий пояс робочого процесу та збереження історії виконання.
• Тримайте експортовані робочі процеси вільними від вбудованих справжніх секретів.

Офіційна документація: Розгортання n8n у Docker

Встановіть публічне походження webhook для встановленого випуску

Зворотний проксі, наприклад Caddy, звертається до n8n внутрішньо, тоді як зовнішні сервіси викликають його HTTPS походження webhook. Використовуйте змінну URL webhook, задокументовану для встановленого випуску; поточна документація називає N8N_WEBHOOK_URL, тоді як старіші випуски використовували WEBHOOK_URL. Встановіть реальну кількість переходів проксі, а не довіряйте довільним переданим заголовкам. Тримайте політику доступу редактора окремо від автентифікації webhook і переконайтеся, що робочий зворотний виклик не містить внутрішнього хоста чи порту.

# Example values for a supported current release, behind one proxy:
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1

Офіційна документація: налаштування зворотного проксі для вебхука n8n

Перевірте безпечний робочий процес, перш ніж надавати доступ на запис

Почніть із запиту лише для читання або одноразового тестового запису. Перевірте робочий вебхук ззовні VPS, відхилення автентифікації та навмисну повторну спробу. Повторний запит не повинен випадково створити другу значущу дію. Перевірте журнали виконання на витік вхідних даних, потім застосуйте політику зберігання. Якщо вебхук працює лише в тестовому режимі редактора, перевірте, чи робочий процес опубліковано/активовано і чи робочий та тестовий маршрути ведуть до правильного процесу.

• Використовуйте одноразові інтеграційні облікові дані для перевірки відновлення.
• Зберігайте незалежну зашифровану копію N8N_ENCRYPTION_KEY або згенерованого стану ключа.
• Не надсилайте зразки паролів або токени API у збережений діагностичний вивід.

Офіційна документація: n8n ключ шифрування

Масштабуйте лише після спостереження за вузьким місцем виконання

Режим черги додає Redis, воркери та спільну базу даних; головний процес отримує тригери, тоді як воркери виконують запуски. Кожен воркер повинен використовувати той самий ключ шифрування облікових даних. Дотримуйтеся поточних вимог до зберігання бінарних даних, перш ніж переносити робочий процес із файлами в режим черги. Обмежуйте паралельність і бюджети upstream API, а також відстежуйте вік черги та збої. Резервуйте базу даних, стан і ключ разом; перезапуск контейнера не є планом відновлення для нечитабельних збережених облікових даних.

Офіційна документація: режим черги n8n · Налаштування очищення виконань