n8n’s workflow execution engine orchestrates node processing through an
extensible architecture supporting both in-process (regular) and distributed
(queue) modes. The WorkflowRunner service, located in
packages/cli/src/workflow-runner.ts, acts as the primary entry
point, determining whether to execute a workflow directly in the current
process or enqueue it for a worker. Once execution begins, the
WorkflowExecute class manages the node execution stack,
routing data sequentially and capturing input‑output snapshots at every step.
[1]
[2]

How does n8n’s execution engine process nodes in a workflow?

n8n uses a stack‑based execution model: the WorkflowExecute class
initialises an execution stack containing the trigger node, then
processes nodes sequentially via processRunExecutionData().
After each node executes, the engine captures its output JSON and routes
data to downstream nodes by calling addNodeToBeExecuted(),
maintaining full execution state until every node is complete.
[1]

The engine supports two execution orders: v0 (legacy) and v1. The
ActiveExecutions service tracks all currently running
executions in the process, manages response promises for webhook‑triggered
workflows, and provides cancellation capabilities through
finalizeExecution()
[1].
For how this architecture underpins production‑grade workflows, see the
n8n Architecture Hub.

What are the two execution modes in n8n and when should you use each?

n8n provides two execution modes controlled by the
EXECUTIONS_MODE environment variable: regular
(default) runs everything in a single process—UI, API, and workflow
execution; queue delegates execution jobs into a Redis‑backed
Bull queue where separate worker processes pick them up and process them
independently, isolating execution from the main instance.
[2]

Regular mode is ideal for development and single‑server deployments with
fewer than approximately 200 executions per day—beyond that, a single
CSV‑processing workflow can block the UI for 30+ seconds and cause webhook
timeouts
[3].
Queue mode eliminates this bottleneck by distributing jobs across workers.
For a complete feature breakdown of how scaling capabilities map to n8n
plans, see the
plans comparison guide.

How does n8n queue mode distribute workflow jobs using Redis and workers?

Queue mode splits n8n into three logical segments: the main
process serves the editor UI and listens for triggers (webhooks,
schedules); Redis acts as the message broker via the Bull
queue library, holding job descriptions with workflow IDs, trigger data, and
credential references; and worker processes continuously
poll Redis, grab available jobs, and execute them via WorkflowExecute.
[3]
[4]

Workers run a tight loop—check queue, grab a job, execute, write results
to PostgreSQL, repeat. PostgreSQL stores workflow definitions, credentials,
and execution history, providing the shared state that lets any worker
execute any workflow. Because the main process only enqueues jobs and never
executes them directly, the UI remains responsive even when a worker is
crunching through 10,000 spreadsheet rows
[3].
For setting up secure self‑hosted instances with this architecture, see the
self‑hosting security guide.

How does n8n manage memory per execution and what causes out‑of‑memory errors?

n8n does not restrict the amount of data each node can fetch and process.
Out‑of‑memory errors occur when a workflow execution requires more memory
than the instance has available. Key factors that increase memory usage
include the volume of JSON data, the size of binary data, the number of
nodes, and the use of Code or old Function nodes.
[5]

On n8n Cloud, each plan has a hard memory limit per execution: Starter plan
imposes 320 MiB, Pro plan raises this to 640 MiB,
and Pro‑2 provides 1280 MiB. These limits are not
adjustable per instance—you must upgrade your plan to increase the ceiling
[6].
For self‑hosted instances, set --max-old-space-size=SIZE via
the NODE_OPTIONS environment variable to increase the V8 heap
size. The most effective mitigation for large datasets is to split processing
into batches—for example, processing 500–1000 rows at a time with the
SplitInBatches (Loop Over Items) node.

How do execution timeouts and concurrency limits control n8n’s performance?

n8n provides two timeout controls: EXECUTIONS_TIMEOUT (default
-1, disabled) sets a global default timeout in seconds for
all workflows, while EXECUTIONS_TIMEOUT_MAX (default
3600 seconds) caps the maximum timeout that users can set
per individual workflow. Set EXECUTIONS_TIMEOUT to 3600 for a
1‑hour default limit.
[7]

Concurrency is governed by N8N_CONCURRENCY_PRODUCTION_LIMIT
(default -1, disabled in regular mode). In queue mode, each
worker reports its processing capacity, and n8n dispatches jobs accordingly.
N8N_AI_TIMEOUT_MAX (default 3,600,000 ms) is
specific to AI and LLM nodes, accommodating slower local AI services. For
performance‑sensitive deployments, consult the
scaling & concurrency configuration guide.

What is the Node.js runtime environment that n8n’s engine executes within?

n8n’s engine runs on Node.js 18 or higher, with LTS
versions 18.x and 20.x recommended for production. The main and worker
processes each run as separate Node.js processes. On self‑hosted
deployments, memory is controlled by V8’s --max-old-space-size
flag, while on Cloud, memory is capped per plan as described above.
[8]

Beyond execution, the Code node (n8n-nodes-base.code) also
runs on Node.js 18 for JavaScript and Pyodide (CPython compiled to
WebAssembly) for Python. Task Runners further isolate code execution: in
internal mode, they run as Node.js sub‑processes of the n8n instance; in
external mode, they run in fully isolated containers. For detailed runtime
configuration of Task Runners, see
n8n Code Node transformation guide.