n8n improves worker shutdowns in queue mode

A worker restart should not break work halfway through

An n8n worker may be running a long task exactly when you need to update a Docker image, reboot the host, or deploy a configuration change. That happens regularly in a homelab: Proxmox maintenance, system updates, Docker Compose changes, or a test that eventually reaches production. If the process stops without any margin, an active execution can be left halfway through its work.

n8n 2.43.7 includes an improvement aimed at that situation for workers running in queue mode. The release notes state that in-flight production executions can be suspended when a worker shuts down instead of relying on an abrupt process termination. This matters when n8n handles work that is not instantaneous, such as synchronizations, backups, chained HTTP calls, or Laravel-connected automation. (github.com)

What queue mode changes

In queue mode, the main n8n instance receives triggers and places pending executions in Redis. Workers pick up those jobs, retrieve the required workflow data from the database, and run the workflows. That separates the editor and webhook handling from the actual workload, while also making it possible to add or remove workers when needed. (docs.n8n.io)

You do not need a large infrastructure for this setup to make sense. Even one additional worker can make a restart or container replacement less risky, as long as the workers share Redis, the database, and the same encryption key. In a homelab, the value is often operational control rather than raw scaling capacity.

The important part is not treating a worker as a disposable process that can disappear at any time. If an automation is uploading a file, waiting on a slow API, or finishing a chain of jobs, it needs time to reach a safe point. That is where the documented graceful shutdown configuration becomes useful.

The setting worth checking

n8n documents N8N_GRACEFUL_SHUTDOWN_TIMEOUT as the time a worker waits before ending the process. Its default value is 30 seconds, and it is intended to give workers time to finish jobs before termination. I would not choose that value arbitrarily: it should reflect the normal duration of the slowest nodes in your workflows. (docs.n8n.io)

This Docker Compose example shows a minimal worker connected to Redis. It does not include the main n8n instance or the database, but it contains the settings the worker needs for queue mode and a practical shutdown window.

services:
  redis:
    image: redis:7
 
  n8n-worker:
    image: n8nio/n8n:2.43.7
    command: worker --concurrency=5
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_GRACEFUL_SHUTDOWN_TIMEOUT: 60
    depends_on:
      - redis

EXECUTIONS_MODE=queue needs to be set on both the main instance and every worker. Workers must also use the same N8N_ENCRYPTION_KEY as the main instance so they can access stored credentials. The official documentation also requires Redis and the database to be available to every process in the deployment. (docs.n8n.io)

The worker --concurrency=5 command caps a worker at five parallel executions. n8n documents a default concurrency of 10 and advises against setting it too low when many workers are involved, as that can put unnecessary pressure on the database connection pool. In a homelab, the right number depends on RAM, CPU, and external services more than on any generic recommendation. (docs.n8n.io)

How I would use it in a homelab

I would keep Redis and the worker separate from the main n8n container once workflows receive webhooks or run frequent jobs. Laravel can send a webhook to n8n after a business event, while n8n handles a backup, notification, or call to another service. That does not require a complicated distributed platform, but it does benefit from restarts that are not a gamble.

Before an update, I would check for active executions and stop the container normally instead of forcing it down. The timeout also needs to be shorter than the time Docker or your orchestrator allows before killing the process, otherwise n8n never gets to use its own shutdown window. I would test this first with a slow but disposable workflow before applying the pattern to automations that move real data.

If you run several workers, they should all use the same n8n version. The documentation explicitly requires this for multi-main deployments, and it is a sensible precaution for workers sharing a queue, Redis, and a database as well. Updating containers one at a time may feel conservative, but it avoids version differences that are difficult to troubleshoot. (docs.n8n.io)

The fine print

Graceful shutdown does not make an execution indestructible. If the host loses power, Docker receives a forced termination, or the grace period expires while a node is still blocked, the process may still be unable to finish cleanly. This change reduces one specific failure mode during orderly shutdowns; it does not replace backups, monitoring, or idempotent workflow design.

I would also avoid queue mode with binary data stored on the local filesystem. n8n states that this combination is unsupported and recommends external storage such as S3 when workflows need persistent binary data. A shared volume may seem good enough in a lab, but it creates dependencies and failure modes as soon as a worker moves to another machine. (docs.n8n.io)

There is a practical webhook trade-off as well. In queue mode, the main process or a webhook processor receives the HTTP request, but a worker runs the workflow itself. That extra handoff adds some overhead and latency. It is usually fine for internal or asynchronous work, but endpoints that must respond quickly should be measured before anything is redesigned. (docs.n8n.io)

The value of n8n 2.43.7 is straightforward: it makes n8n easier to operate as part of a homelab infrastructure. It is not a flashy UI feature, but it is useful when updating, rebooting, and maintaining workers without treating every deployment as an unavoidable interruption to automation.

Source: n8n 2.43.7 release · Official queue mode documentation