n8n is a powerful open-source workflow automation tool that allows building complex workflows without deep programming. One of the key scaling mechanisms in n8n is queue mode, where the main instance delegates task execution to separate processes called workers. Workers allow distributing load, enabling parallel workflow execution and improving system performance.

In the n8n community and practical guides, two types of workers are often distinguished: light workers and heavy workers. Although the official documentation doesn’t use these terms directly, they reflect differences in task types and configuration. Light workers are aimed at fast, frequent operations, while heavy workers handle resource-intensive tasks. In this article we’ll examine their differences, how they work, and why they are necessary for effective scaling.

What is queue mode in n8n?

Before moving to worker types, briefly about the context. In queue mode n8n separates responsibilities:

• Main instance — handles the UI, API, webhooks, and triggers. It does not execute workflows itself, but only places them into a queue in Redis (message broker).
• Workers — separate Node.js processes that take tasks from the Redis queue, execute workflows, and return results to the database (Postgres recommended).
• Webhook processors (optional) — specialized processes for handling incoming webhooks.

This allows horizontal scaling: adding workers as load grows. Redis manages the queue, and the concurrency parameter in workers determines how many tasks can be executed concurrently on a single worker (default is 10).

Light workers: for fast and frequent tasks

Light workers are “light” processes designed to handle simple, high-throughput operations. They are ideal for scenarios with peak loads where speed and volume matter.

Key characteristics:

• Task type: webhook triggers, simple workflows with small data volumes, frequent API calls.
• Configuration: high concurrency (default 10 or higher) to process many tasks in parallel.
• Advantages: quick response to events, minimal resource consumption per task.
• Example use: handling notifications from a Telegram bot or integrating with Stripe — thousands of small requests per minute.

Note on Webhook Processors: You can deploy separate processes with the n8n webhook command. This process does not execute workflows — its job is to quickly accept the webhook request, put it in a queue (for example, default or webhooks) and respond “OK”. The actual execution will be taken by a light worker listening to that queue. This offloads the main UI and ensures system responsiveness.

Heavy workers: for resource-intensive operations

Heavy workers, conversely, are “heavy” — they take on complex, compute-intensive tasks where CPU, memory and I/O are critical.

Key characteristics:

• Task type: processing large files, bulk API requests, AI steps (e.g., LLM text generation), or workflows with large data volume.
• Configuration: low concurrency (recommended 5 or less) to avoid overloading. Use Split In Batches and external storage (e.g., S3) for large data.
• Advantages: stability under load and protection from system crashes.
• Example use: automating video processing or analyzing large Google Sheets.

Heavy workers prevent a situation where heavy tasks slow down the queue of fast tasks.

How to implement separation into light and heavy

In n8n separation is implemented not via separate process types but via named queues.

By default all tasks go to the default queue. To split them:

1. Assign the workflow to the appropriate queue

In Workflow → Settings → Queue specify the queue name:

• for heavy tasks — heavy_tasks;
• for light tasks — default or light_tasks.

2. Start heavy-workers

docker run -d \
  -e QUEUES=heavy_tasks \
  -e N8N_WORKER_CONCURRENCY=3 \
  n8nio/n8n worker

This worker will take tasks only from the heavy_tasks queue and process a maximum of 3 tasks concurrently.

3. Start light-workers

docker run -d \
  -e QUEUES=default,light_tasks \
  -e N8N_WORKER_CONCURRENCY=20 \
  n8nio/n8n worker

These workers listen to queues for fast processing and do not touch heavy tasks.

Comparison of light and heavy workers

Why this is needed

Without queue mode all load falls on a single process, and one heavy workflow can block the UI. Separation into light and heavy solves this problem:

1. Scalability — you can horizontally increase workers.
2. Performance — heavy tasks don’t interfere with fast ones.
3. Reliability — isolation of failures between pools.
4. Resource efficiency — you use resources according to purpose.

As a result the system remains responsive, reliable, and ready for production-level loads.

Conclusion

Light and heavy workers are not strict categories but an engineering pattern that helps effectively use the capabilities of queue mode in n8n. Light for speed, heavy for stability. Together they enable building scalable, resilient and cost-effective automation systems.