---
title: "Task runners в n8n: Python, JavaScript, изоляция — Nodbot"
source_url: "https://nodbot.ru/hosting/task-runners/"
canonical_url: "https://nodbot.ru/hosting/task-runners/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 1034
---

# Task runners в n8n: Python, JavaScript, изоляция Code node и безопасный запуск

## AI summary

Production-гайд «Task runners в n8n: Python, JavaScript, изоляция Code»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации.

## Best used for

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

## Key topics

- Что делает task runner
- Когда task runners действительно нужны
- Минимальная схема Docker Compose
- Как писать Code node под runner
- Smoke-test для JavaScript
- Smoke-test для Python
- Безопасность
- Типовые ошибки

## Source outline

# Task runners в n8n: Python, JavaScript, изоляция Code node и безопасный запуск

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

Code node — мощная вещь: можно трансформировать items, чистить данные, готовить payload, работать с JSON и писать Python/JavaScript. Но именно пользовательский код чаще всего становится риском: он может зависнуть, съесть память, случайно вывести секрет или выполнить слишком тяжёлую операцию. Task runners нужны, чтобы выполнение кода было отделено от основного процесса n8n.

В production лучше использовать внешний runner-процесс, а не полагаться на внутренний режим. Тогда main instance остаётся редактором и оркестратором, а пользовательский код исполняется отдельно.

## Что делает task runner

```
n8n main / worker → task broker → task runner → результат обратно в execution
```
Runner получает задачу от n8n, исполняет код и возвращает результат. Для команды эксплуатации это важная граница: можно ограничить ресурсы runner, обновлять его отдельно и не давать пользовательскому коду ломать основной контейнер.

## Когда task runners действительно нужны

- Сценарий | Нужен runner? | Почему
- простые выражения и Set/Edit Fields | нет | Code node не нужен
- массовая нормализация JSON | да | лучше изолировать CPU/memory
- Python для файлов, CSV, PDF | да | важны зависимости и ограничения
- выполнение shell-команд | нет, это другая зона риска | используйте Execute Command только в изолированном контуре

## Минимальная схема Docker Compose

Названия переменных могут меняться между версиями n8n, поэтому сверяйте их с документацией вашей версии. Смысл настройки такой: включить task runners, указать broker, общий auth token и отдельный runner-сервис.

```
services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      N8N_RUNNERS_ENABLED: "true"
      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0
    ports:
      - "5678:5678"
    restart: unless-stopped

  n8n-runner:
    image: n8nio/runners:latest
    environment:
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
    depends_on:
      - n8n
    restart: unless-stopped
```
Не публикуйте broker port наружу. Он должен быть доступен runner внутри Docker network или Kubernetes pod/network, а не всему интернету.

## Как писать Code node под runner

- Не делайте бесконечные циклы. У каждого workflow должен быть лимит items и понятный timeout.
- Не храните секреты в коде. Берите токены из credentials или env, но не выводите их в лог.
- Возвращайте массив items в ожидаемом формате, не меняйте структуру хаотично.
- Для тяжёлой обработки файлов лучше сохранять файл в S3/MinIO и передавать ссылку/metadata.
- Пишите малые функции: normalize, validate, map, enrich. Не превращайте Code node в микросервис.

## Smoke-test для JavaScript

```
return items.map((item, index) => ({
  json: {
    ...item.json,
    normalized_at: new Date().toISOString(),
    row_number: index + 1
  }
}));
```
После запуска проверьте логи runner и execution data. Если код выполнился, но output пустой, проблема чаще в формате возвращаемых items, а не в runner.

## Smoke-test для Python

```
from datetime import datetime

for item in items:
    item["json"]["normalized_at"] = datetime.utcnow().isoformat() + "Z"
    item["json"]["source"] = item["json"].get("source", "n8n")

return items
```
Python особенно чувствителен к версии n8n и режиму runner. Если Python не стартует, не лечите это случайными пакетами в main container: проверьте, как именно ваша версия n8n поддерживает Python Code node и runners.

## Безопасность

- Риск | Как снизить
- код читает лишние файлы | не монтировать чувствительные volumes в runner
- утечка токенов в лог | не печатать credentials/env, маскировать debug
- нагрузка на CPU | ограничить ресурсы контейнера/пода
- зависшие executions | таймауты, batch size, мониторинг queued/running

## Типовые ошибки

- Runner не подключается. Проверьте token, broker URI, Docker network и доступность порта broker.
- Code node работает локально, но падает в production. Сравните версии n8n и runner, режим исполнения и доступные зависимости.
- Execution зависает. Ограничьте batch size, уберите тяжёлую обработку из одного запуска, проверьте логи runner.
- Output потерял items. Проверьте, что Code node возвращает массив items, а не один объект.

## Связанные инструкции

- Code node: JavaScript и Python
- Execute Command и безопасность
- n8n в Kubernetes и Helm
- Queue mode и workers

## Операционный runbook для self-hosted

Для темы «Task runners в n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”.

Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key.

- Слой | Что зафиксировать | Зачем
- Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам
- Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Task runners в 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
```

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

- есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY
- web, worker, queue и database используют согласованные переменные окружения
- после изменения проверены логи, healthcheck и запуск критичных workflow
- записан rollback-план с командами и ответственным

## Эксплуатационный контекст для self-hosted n8n

Страницу «Task runners в n8n: Python, JavaScript, изоляция Code node и безопасный запуск» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup.

Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution.

### Ops-чеклист перед изменением

- Сделайте backup базы, файлового хранилища и критичных env-переменных.
- Проверьте, что есть понятный rollback и окно обслуживания.
- Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs.
- Проведите тест webhook, scheduled workflow и ручного запуска.
Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом.

### Связанные материалы для эксплуатации

- Self-hosted n8n — открыть связанный материал для проверки контекста.
- Логи и мониторинг — открыть связанный материал для проверки контекста.
- Backup и update — открыть связанный материал для проверки контекста.
- Launch checklist — открыть связанный материал для проверки контекста.

## Related Nodbot pages

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

## Retrieval hints

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