How Does n8n Execute Workflows? Engine, Queue Mode & Memory Guide

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.