n8n workflow architecture
Operating n8n involves more than connecting nodes. Configuration, credentials, queues and version changes affect how a workflow behaves. Start by understanding which component owns each responsibility, then validate the configuration for your installed version, edition and workload.
A reading guide by Idir OuhabSeparate configuration from execution
A variable supplies configuration to a workflow; its scope determines where that value is available. A credential supplies authentication. Keep secrets in credentials or an appropriate secrets system, rather than ordinary shared variables. Queue mode addresses a different concern: distributing executions to workers. Before adding workers, identify the bottleneck and the dependencies that all workers must reach.
Draw the path of one execution
For a workflow triggered by a webhook in queue mode, trace how the request reaches n8n, how the execution is queued, which worker runs it and where its state is stored. Include any task runner needed by the nodes you use. Then interrupt one dependency in a test environment: does the request fail, wait or retry, and can you tell which external actions already happened? The drawing becomes useful when it explains a failure, not just when every service is healthy.
A suggested reading order
Follow the sequence or start with the question you need to resolve.
n8n Introduces Project-Scoped Variables: A Game-Changer for Team Collaboration
Start with project-scoped variables to distinguish shared configuration from values intended for one project.
Feature availability depends on the edition and plan as well as the installed version. Variables do not replace credential management.
3 min read
Scaling n8n: queue mode, workers and task runners
Use the queue-mode article to understand the components and the questions to ask when splitting execution across workers.
The earlier deployment recipe has been removed. The revised article explains the architecture and configuration responsibilities; it does not provide an end-to-end validated setup.
8 min read
n8n 2.0: changes and context for the 2025 migration
Then read the n8n 2.0 article for the migration issues discussed at that release, and compare them with the notes for your actual starting and target versions.
Historical context from the December 2025 release. It is not a checklist for every later n8n upgrade.
10 min read
Before you decide
Use these questions to make the next decision explicit.
Record versions and feature availability
Check the n8n version, edition, node dependencies and runner compatibility. Read the release-specific migration notes before an upgrade.
Separate settings and secrets
Document which values are global or project-scoped. Keep passwords and API keys in credentials or an appropriate secrets system.
Map workers and shared dependencies
Identify the main instance, queue, database and workers, plus any runners or binary-data storage. Verify connectivity and access for each component.
Practise load and recovery
Test realistic execution sizes, concurrency and dependency failures in a separate environment. Verify backups and a rollback procedure before changing the live deployment.
Scope and limits
The reading path explains architecture decisions. Each deployment needs tests with its own version, workflows and infrastructure. The queue article explains component connections, and the migration article preserves the context of the December 2025 release.
Check the implementation details
Use the current n8n documentation to confirm variable availability, queue configuration and task-runner requirements before implementing a change.
Review a workflow your team operates
Training can build a shared understanding of configuration and execution. Advisory can review a specific workflow or deployment decision using its architecture, constraints and available evidence. We agree what to examine before starting.