Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Hundreds of idle n8n workflows can use little capacity while a few heavy workflows generate intense execution load. Current n8n docs position queue mode as the best scalability model: the main instance enqueues work in Redis, workers execute jobs and Postgres stores persistent data.
Queue mode distributes execution work from the main process to worker instances. Workers can scale horizontally and `--concurrency` controls jobs per worker. Queue mode requires Redis and a supported production database setup.
The main instance coordinates workflows and triggers/webhooks, jobs enter Redis and workers execute them while persistent state is stored in the database.
A short HTTP workflow and a code-heavy file-processing workflow consume very different CPU/memory time.
n8n queue-mode workers support concurrency controls. CPU-heavy code tasks and IO-bound API workflows may not perform well at the same concurrency. Task runners also require worker-side deployment considerations.
Container names vary by Compose stack; inspect main, workers, Redis and Postgres independently.
Turkey (Turkish)
Germany (German)
Worldwide (English)
docker compose psdocker stats --no-streamdocker compose logs --tail=100 workerdocker compose logs --tail=100 n8nredis-cli PING 2>/dev/null || truepg_isready 2>/dev/null || trueEncryption keys, database state, binary-data strategy and webhook URLs must remain consistent during migration.
Yes. Queue mode distributes execution jobs between main and workers through a Redis-backed queue.
It depends on execution rate, average duration, concurrency and workload type; workflow count alone is not enough.
Current n8n documentation states queue mode provides the best scalability.
Share executions per minute, average workflow duration, binary payloads, Code nodes and webhook volume; we can design main/Redis/Postgres/worker topology.