n8n’s execution engine is built on a stack‑based, sequential processing
model implemented by the WorkflowExecute class — it maintains a node
execution stack, processes nodes one by one via
processRunExecutionData(), and routes data downstream through
addNodeToBeExecuted(). The WorkflowRunner serves
as the primary entry point, deciding at execution time between regular
mode (direct in‑process execution via
runMainProcess()) and queue mode (distributed
execution via enqueueExecution() through a Redis‑backed Bull job
queue). Queue mode requires PostgreSQL because SQLite cannot handle concurrent
multi‑process writes, uses Redis ≥6.0 as the message broker, and distributes
jobs to worker processes that independently fetch workflow
definitions from PostgreSQL, execute nodes, and write results back [1]
[2].

How does n8n’s stack-based engine determine node execution order in parallel branches?

n8n processes nodes sequentially using a stack-based model
maintained by the WorkflowExecute class: it initialises a node
execution stack with the trigger, processes each node via
processRunExecutionData(), captures its output JSON, and
routes data to downstream nodes with addNodeToBeExecuted(),
repeating until the stack empties. The engine supports two execution
orders: v0 (legacy) and v1 (recommended).
[1]
[3]

In v1 mode, n8n completes each branch in turn before
moving to the next — branches are ordered by their position on the
canvas from topmost to bottommost; if two branches sit at the same
height, the leftmost executes first. In v0 mode, n8n
executes the first node of every branch, then the second node of every
branch, and so on — interleaving execution across branches. The execution
order is configurable per workflow under Workflow Settings → Parallel
Branch Execution Order. V1 is recommended for all workflows created in
version 1.0 and above; v0 remains available as a legacy option for
compatibility. The ActiveExecutions service tracks all
currently running executions, managing response promises for webhook-
triggered workflows and providing cancellation via
finalizeExecution() [1].
For a complete walkthrough of the WorkflowExecute class and the
runMainProcess() vs enqueueExecution()
decision, see the n8n Node Execution Hub.

How does queue mode distribute workflow executions using Redis, workers, and PostgreSQL?

Queue mode splits n8n into three logical component types: the
main process serving the editor UI, REST API, and
trigger listening; Redis ≥6.0 acting as the message
broker via the Bull job queue library; and worker processes
continuously polling Redis for jobs, executing workflows independently
via WorkflowExecute, and writing results back to PostgreSQL [2]
[5].

Queue mode requires PostgreSQL because SQLite cannot
handle concurrent multi-process writes: multiple worker processes must
read and write workflow definitions, execution state, and results
simultaneously — SQLite’s file-level write lock causes “database is
locked” errors and corruption under this load [6].
PostgreSQL handles this natively through MVCC with row-level locking.
The complete six‑step flow: (1) trigger reception generates
an execution, (2) execution record stored in PostgreSQL, (3) execution ID
pushed to Redis Bull queue, (4) next available worker pops the job, (5)
worker fetches full workflow definition and credentials from PostgreSQL,
(6) worker executes all nodes and writes results back to PostgreSQL [2].
Workers are stateless: you can add or remove them without downtime, and a
single worker failure never loses queued jobs. The encryption
key (N8N_ENCRYPTION_KEY) must be identical across
the main process and every worker. For the complete production deployment
blueprint with Docker Compose, see the n8n Docker Compose production stack guide.

How does N8N_CONCURRENCY_PRODUCTION_LIMIT control how many workflows run simultaneously?

N8N_CONCURRENCY_PRODUCTION_LIMIT is a single environment
variable that caps the number of production executions running at the
same time — in both regular and queue modes. It
defaults to -1 (disabled). When set to any value other
than -1, it overrides the per-worker --concurrency flag in
queue mode and becomes the global ceiling for the entire deployment. This
limit applies only to production executions from webhooks and trigger
nodes — manual executions, sub-workflow calls, error executions, and CLI
executions are exempt [7].

Set it to a reasonable value (e.g., export N8N_CONCURRENCY_PRODUCTION_LIMIT=20)
to prevent event-loop thrashing caused by too many simultaneous production
executions [7].
In queue mode, if this variable is -1, each worker’s concurrency is
determined by its --concurrency startup flag (default:
10 per worker) [8].
The per-worker default of 10 means each worker runs up to 10 jobs in
parallel; a value less than 5 can lead to an unstable environment [8].
Executions beyond the limit are queued and processed in FIFO
order as slots free up. On instance startup, n8n resumes queued
executions up to the concurrency limit and re-enqueues the rest. The
environment variable’s value is consumed once at startup; runtime changes
require a restart [7].
For complete scaling strategies including worker-to-core ratios and
high-availability configurations, see the n8n Scaling & Queue Configuration guide.

How does n8n manage memory, how much does each execution consume, and what causes OOM errors?

n8n does not restrict the amount of data each node can fetch and process
— it uses a Node.js 18 runtime where the V8 engine
manages heap memory. Memory consumption scales with three
primary factors: the volume of JSON data passing through nodes,
the size of binary data, and the number of nodes in a workflow.
Code nodes and the legacy Function node increase consumption
significantly [9].

On n8n Cloud, the memory limit varies by plan: 320–640 MiB
for Starter/Pro [10].
On self-hosted instances, you can increase the V8 heap size via
NODE_OPTIONS="--max-old-space-size=SIZE" or scale the
container memory [9].
Telltale warning signs include “Execution stopped at this node (n8n may
have run out of memory)” messages, “Allocation failed — JavaScript heap
out of memory” in server logs, and Connection Lost or 503 Service
Temporarily Unavailable responses [9].
To reduce memory consumption: process data in smaller chunks (e.g., 200
rows instead of 10,000), avoid manual executions (n8n duplicates data
for the frontend), and split large workflows into sub-workflows so each
returns only limited output to the parent [9].
For the complete memory tuning and monitoring guide, see the n8n Node Execution Hub.

How do execution timeouts work, and how do they control long-running workflows?

n8n provides two-tier timeout control. The first tier,
EXECUTIONS_TIMEOUT, sets a default timeout in seconds for all
workflows — it defaults to -1 (disabled). When set, n8n
first attempts a soft timeout (waits for the current node
to finish), then kills the process after waiting for a fifth of the given
timeout duration [11].

The second tier, EXECUTIONS_TIMEOUT_MAX, sets the maximum
timeout users can configure per individual workflow — defaulting to
3600 seconds (1 hour) [12].
Example: export EXECUTIONS_TIMEOUT=3600 for a 1-hour default
across all workflows, and export EXECUTIONS_TIMEOUT_MAX=7200
for a 2-hour ceiling on per-workflow overrides. This two-tier system
means the instance admin can enforce a hard global ceiling that no
individual workflow can exceed. Users can override
EXECUTIONS_TIMEOUT in the Settings tab of each individual
workflow up to the EXECUTIONS_TIMEOUT_MAX ceiling. For AI
and LLM nodes (OpenAI, Anthropic, Mistral, Ollama) that may need longer
processing, a separate N8N_AI_TIMEOUT_MAX variable controls
the HTTP request timeout at 3,600,000 ms (1 hour)
default [12].
For complete error handling and retry patterns that catch timeout
failures, see the n8n Error Handling nodes guide.

How does the complete regular-mode execution lifecycle go from trigger to data written to database?

In regular mode, the lifecycle begins when a trigger
fires (webhook, schedule, manual). The WorkflowRunner
is the primary entry point that decides between runMainProcess()
and enqueueExecution() based on the
executions.mode configuration [13].
Regular mode takes the runMainProcess() path — executing the
entire workflow in the current Node.js process.

The lifecycle progresses through four phases. Phase 1 — Registration:
ActiveExecutions.add() creates the execution record and
ExecutionRepository.setRunning() marks the start time in the
database. Phase 2 — Engine Invocation:
WorkflowExecute.run() initialises the node execution stack.
Phase 3 — Node Processing: the engine pops each node from
the stack, executes it, captures its output JSON, routes data to downstream
nodes via addNodeToBeExecuted(), and repeats until the stack
empties. Phase 4 — Finalisation: results are written to the
database, binary data to configured storage, and
ActiveExecutions.finalizeExecution() releases the execution
tracking slot [13].
For production deployments above ~200 workflow executions per day, switch to
queue mode to separate the UI from execution and enable horizontal scaling —
the complete production blueprint is available in the Docker Compose production stack guide.