@firmansi Yes, that is exactly what I mean.
Just to avoid a misunderstanding: I am not necessarily asking for multiple separate Cloudron n8n app instances to be connected manually.
What I would like to see is support for Queue Mode inside the existing official Cloudron n8n package. In my test setup, this worked as a single Cloudron app where the configuration allowed setting the number of workers. On app startup, the app then started the main n8n process plus the configured number of worker processes.
From a user perspective, this could still remain one Cloudron app:
- n8n main process for UI, webhooks and triggers
- Cloudron Redis as the queue backend
- configurable number of n8n worker processes
- worker count set through config/env
- workers started automatically when the app starts
@joseph This is different from N8N_CONCURRENCY_PRODUCTION_LIMIT.
Concurrency control can help prevent overload by limiting how many executions run at the same time. That is useful, and I will test it. But it does not solve the core issue I am seeing.
My workflows sometimes process more than 100,000 items. The workflows are already optimized with batching where possible, but without Queue Mode, the n8n UI still becomes unresponsive while executions are running. In many cases, it is basically luck whether the jobs finish or whether the whole n8n instance crashes and needs to be restarted.
With my Queue Mode test, batching was still required so the workload could be split properly across executions/workers. But the important difference was that the UI stayed responsive because the main process was not doing all the heavy execution work itself. This made the system much more usable and stable.
So I agree that concurrency control may improve stability in some cases, but it is not a replacement for Queue Mode. My request is about making the official Cloudron package capable of running n8n in this architecture, preferably with a simple way to configure the number of workers.
