Queue mode setup with a dedicated webhook processor — compose stack + docs

Feature Requests Nodes
,
1

I kept running into the same thing when self-hosting n8n: everything works fine until a burst of production webhooks hits the main process and the editor becomes unusable. Splitting the webhook processor out fixed it, but I couldn’t find a single reference setup that put all the pieces together, so I built one and documented it.

What it does:

  • Main, workers and webhook processor as separate services
  • Caddy routing /webhook/, /webhook-waiting/, /form/* and /form-waiting/* to the dedicated processor, everything else to main
  • Postgres + Redis with maxmemory-policy noeviction (the default policy silently drops Bull jobs under memory pressure)
  • Pinned n8n version, execution pruning on by default
  • A check script that verifies the encryption key is identical across main, worker and webhook — that mismatch produced the most confusing failures I ran into

I deliberately broke it to see how it behaves: killed workers mid-execution, flooded the queue, cut Redis.

Docs are in Spanish, since that’s the gap I was trying to fill. The configuration itself is language-agnostic.

Happy to hear where this is wrong — particularly around scaling workers and webhook processor replicas.

2

Nice work, especially testing worker loss, queue flooding, and Redis failure instead of publishing only the happy path.

One additional check I will consider is monitoring both queue depth and oldest-job age. A worker pool can looks healthy while execute latency quietly increasing, It would also be useful to document what happens during scale-down or redeployment: whether in-flight executions drain cleanly, and what webhook callers received when Redis or the workers are unavailable.

Have you defined the expected delivery outcome for each failure mode? like accepted, retried, delayed, or rejected? adding that would make this useful as a production runbook as well as a Compose reference