The 5 Python errors every n8n self-hoster hits, and the fixes

Four characters into your first Code node, the workflow halts. n8n run python script errors are among the most-searched issues on community.n8n.io, and for good reason: the n8n 2.0 release in December 2024 restructured how Code nodes execute, turning an optional performance toggle (the external task runner) into a hard dependency.

Workflows that ran cleanly on n8n 1.x started throwing socket errors, sandbox violations, and "Python not found" messages without a single line of code changing. This article maps each failure mode to its exact root cause and provides a targeted fix, not a general "check your environment" suggestion.

Why n8n run python script errors cluster around version upgrades

Understanding where execution breaks requires a picture of the three architectural layers n8n passes through when running a Python script.

Before n8n 2.0, the Code node ran inside a sandboxed VM within the main n8n process. Python support worked by calling the system python3 binary, writing the script to a temp file, and piping stdout back into the workflow. This functioned on custom Docker images that included Python, but it never worked on the official n8nio/n8n base image, which ships on Alpine Linux with no Python binary included.

n8n 2.0, released December 2024, introduced the external task runner as a mandatory component for all Code nodes. The runner is a separate process (or container) that receives execution payloads from n8n over a socket and returns results. This added two new failure surfaces: the runner must be present and reachable, and its module policy must allow what the script imports.

The three layers where a Python script not working in n8n can break:

1. System binary layer (python3 is absent or at an unexpected path)
2. Sandbox layer (the runner's import policy blocks the modules the script uses)
3. Runner process layer (the task runner is missing, unreachable, or unauthenticated)

Most n8n Python setup problems trace to one of these three layers. The next sections address each error by its exact message.

Error 1: "Python 3 is missing from this system" on a Docker install

The official n8nio/n8n Docker image is built on Alpine Linux. Alpine ships no Python by default, and the n8n maintainers have not added it to the base image. When the Code node calls python3, the binary is absent and n8n throws "Python 3 is missing from this system."

This issue was still reproducible on images up to n8n 2.6.x as of February 2026.

The fix is a two-line Dockerfile extension:

FROM n8nio/n8n:latest
USER root
RUN apk add --no-cache python3 py3-pip
USER node

Build this locally or in CI, push to your registry, and update your compose file to reference the custom tag. Community-maintained images that pre-bundle Python are also available on Docker Hub (search n8n python and verify the pinned n8n version before using one in production).

One detail that catches people after fixing the binary: scripts that call pip install at runtime will still fail. Package installation must happen at image build time, not inside the Code node. This limitation is addressed in the 2026 summary section.

Error 2: "Security violations detected" (the n8n 2.0 import sandbox)

n8n 2.0 introduced a strict import policy in the Code node sandbox. The runner blocks all Python standard-library modules that perform system-level operations: os, sys, subprocess, pathlib, socket, and several others. A script containing any of these imports raises "Security violations detected" before a single line of business logic executes. This is a code node execution failure unrelated to whether the libraries are installed.

This behavior was first documented in mid-December 2025 on community.n8n.io with n8n version 2.0.2 and task runner version 2.1.1.

Two practical paths forward:

Option A: Move system calls to the Execute Command node. If the script reads files, runs shell commands, or inspects environment variables, use the Execute Command node for those operations and pass the result into the Code node as input. This is the cleanest fix for simple cases.

Option B: Adjust the runner's module policy. The runner accepts an environment variable that specifies permitted modules. Setting N8N_RUNNERS_AUTH_TOKEN alongside the runner's policy configuration unlocks specific stdlib modules without disabling sandboxing entirely. The current list of configurable policy keys is maintained in the n8n task runner documentation.

Error 3: Task runner missing or misconfigured in the compose stack

n8n 2.0 moved code execution into a separate task-runner service. If that service is absent from docker-compose.yml, the Code node silently fails or throws a cryptic socket error. The runner is not bundled with the main n8n container (it must be declared as its own service).

Three environment variables must align between both containers:

Variable	Set on	Example value
N8N_RUNNERS_ENABLED	n8n container	true
N8N_RUNNER_SERVER_URI	n8n container	http://n8n-runner:5679
N8N_RUNNERS_AUTH_TOKEN	both containers	shared secret string

Minimal working compose:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNER_SERVER_URI=http://n8n-runner:5679
      - N8N_RUNNERS_AUTH_TOKEN=${RUNNER_TOKEN}

  n8n-runner:
    image: n8nio/n8n-runner:latest
    environment:
      - N8N_RUNNERS_AUTH_TOKEN=${RUNNER_TOKEN}
    ports:
      - "5679:5679"

As of December 2025, n8n had published no single official compose file combining n8n 2.0, the task runner, Postgres, Redis, and a reverse proxy. Users assembled the stack from three separate documentation pages. The n8n GitHub repository is the most reliable source for current compose examples, as maintainers have updated this area frequently going into 2026.

The one variable pair that must match exactly

N8N_RUNNERS_AUTH_TOKEN must be identical in both containers. A mismatch causes a silent authentication failure: both services start without errors, but every Code node execution returns an empty result or a generic connection error.

Generate the token with openssl rand -hex 32, store it in a .env file, and reference it from both services.

Error 4: Timeout and path failures in the Execute Command node

Two distinct failure modes produce similar symptoms.

Timeout on n8n Cloud. The default task runner timeout for self-hosted installs is 60 seconds, configurable via N8N_RUNNERS_TASK_TIMEOUT. On n8n Cloud the cap is lower and not user-configurable. A GitHub issue filed in February 2026 against version 2.6.3 documents scripts that timeout on Cloud while running successfully on a self-hosted instance with identical payloads.

For Cloud users hitting this ceiling, the practical workaround is to offload the long-running logic to an external endpoint (a Lambda, a VPS, a serverless function) and call it from an HTTP Request node.

Path failures on Linux. The Execute Command node resolves binaries through the shell PATH. On Windows, python resolves to python.exe. On Alpine and most Linux distributions, the executable lives at /usr/bin/python3 or /usr/local/bin/python3. A command written as python script.py will fail with "command not found."

Use absolute paths: /usr/bin/python3 /tmp/myscript.py. Verify the correct path once with a diagnostic Execute Command node running which python3.

Python in n8n in 2026: what works, what is still missing

As of mid-2026, Python execution in n8n is functional but incomplete. The task runner is stable. n8n Python setup problems related to runner connectivity are well-documented. Stdlib access is achievable with the right runner policy. The community maintains Docker base images built on Python 3.12 that work reliably with n8n 2.x.

What is still missing: runtime pip install inside the Code node. There is no mechanism to install packages at workflow execution time. Every third-party library (pandas, httpx, pydantic) must be present in the Docker image at build time. An open GitHub feature request for first-class pip support exists; as of Q2 2026 it carries no scheduled milestone.

Decision tree for choosing the right execution path:

• Pure logic, stdlib only, no system calls: Code node with task runner configured
• Shell commands or file system access: Execute Command node
• Third-party packages: extend the Docker image at build time, then use the Code node
• Long-running scripts or external API calls that risk timeouts: HTTP Request node calling an external service

Maybe I'm wrong, but I think most people hitting these errors just need the Docker fix and the three environment variables. The rest is edge cases 🐛

Key takeaways

The five causes behind n8n run python script errors are: no Python binary in the Alpine base image, the n8n 2.0 sandbox blocking stdlib imports, a missing or misconfigured task runner, timeout caps on Cloud, and OS path mismatches in Execute Command.

The December 2024 architecture change is the common thread. If a workflow broke on upgrade, audit the task runner configuration before inspecting code. Official runner docs and the n8n GitHub issue tracker remain the most reliable sources for version-specific updates.

---

If you self-host n8n and Python workflows broke on upgrade, the external task runner is now mandatory—and your Docker image probably doesn't have Python baked in. The CLI blueprint in the welcome kit shows how to structure reproducible tooling setups that won't ghost you on version bumps.

→ Get the welcome kit