n8n - 💡(How to fix) Fix Cannot GET / when main instance uses EXECUTIONS_MODE=queue behind AWS ALB; same setup works in regular mode [2 comments, 3 participants]

Description

We are running self-hosted n8n on AWS ECS/Fargate behind an AWS Application Load Balancer (HTTPS, custom domain). We can run the instance successfully in regular mode, but whenever we switch the main/web instance to EXECUTIONS_MODE=queue, the root URL starts returning Cannot GET /.

The same infrastructure, same ALB, same database, same Redis, same TLS/proxy settings, and same worker/task-runner sidecars work again as soon as we switch the main instance back to regular.

At this point production is stable again on 2.18.5 with regular mode, but we are filing this because queue mode on the main instance appears broken in our setup, even though the queue-mode docs indicate this should be supported.

What is the error message (if any)?

Browser response at /:

Cannot GET /

We also previously saw ECS/ALB health-check instability while reproducing this, but after cleaning up our deployment configuration the key remaining symptom was still Cannot GET / specifically when the main instance was in queue mode.

To Reproduce

Infrastructure / hosting

• Hosting: self-hosted
• Platform: AWS ECS/Fargate
• Load balancer: AWS ALB
• TLS terminated at ALB
• Custom domain: https://n8n.example.com
• Database: PostgreSQL
• Redis: yes
• Task runners: external sidecar containers
• Main container uses the official Docker image
• Worker container uses the same n8n image with worker command
• Separate task-runner image sidecar

Docker image setup

Main image:

FROM docker.n8n.io/n8nio/n8n:2.18.5

Task runners image:

FROM n8nio/runners:2.18.5

We previously saw the same behavior while testing with 2.17.7.

Main instance runtime configuration (relevant parts)

N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
N8N_LISTEN_ADDRESS=0.0.0.0
N8N_TRUST_PROXY=true
N8N_PROXY_HOPS=1
N8N_SECURE_COOKIE=true
N8N_EDITOR_BASE_URL=https://n8n.example.com
WEBHOOK_URL=https://n8n.example.com/
DB_TYPE=postgresdb
QUEUE_BULL_REDIS_HOST=<redis-host>
QUEUE_BULL_REDIS_PORT=6379
N8N_RUNNERS_MODE=external
N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
N8N_RUNNERS_BROKER_PORT=5679
N8N_NATIVE_PYTHON_RUNNER=true
OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true

The only configuration change required to trigger the issue on the main instance is:

EXECUTIONS_MODE=queue

Worker service

• Separate ECS service
• Starts correctly
• Broker/task-runner logs look healthy
• Migrations complete
• No obvious fatal error in worker bootstrap

Expected behavior

When the main instance is configured with EXECUTIONS_MODE=queue, the editor UI at / should still load normally, and the setup should be able to use workers according to the queue-mode documentation.

Actual behavior

When the main instance is configured with EXECUTIONS_MODE=queue:

• the main container starts
• the process binds correctly
• health endpoints appear to respond
• worker/task-runner services start successfully
• but the browser root URL responds with Cannot GET /

When we change only the main instance back to:

EXECUTIONS_MODE=regular

then:

• the editor UI becomes accessible again
• the same infrastructure starts working again
• the instance is stable

Relevant observations from logs

When the main instance was stable again, the relevant startup logs looked like this:

n8n ready on 0.0.0.0, port 5678
n8n Task Broker ready on 0.0.0.0, port 5679
Registered runner "launcher-javascript" (...)
Registered runner "launcher-python" (...)
Editor is now accessible via:
https://n8n.example.com
Version: 2.18.5

When recovering from the failed attempts / restarts we also saw unfinished executions being recovered/marked crashed, which is expected after repeated restarts:

Found unfinished executions: ...
[Recovery] Logs available, amended execution
Marked executions as `crashed`

What we already checked

• We aligned the main image and task-runner image versions
• We removed deprecated N8N_RUNNERS_ENABLED
• We explicitly set N8N_LISTEN_ADDRESS=0.0.0.0
• We explicitly start the main container with start
• We verified the UI is healthy in regular mode on the same infrastructure
• We verified the instance is currently running 2.18.5
• We verified the worker/task-runner side starts and registers runners

Debug / environment info

• n8n version currently running: 2.18.5
• previously reproduced during rollout with: 2.17.7
• database: PostgreSQL
• Redis: enabled
• execution mode that works: regular
• execution mode that breaks the root UI: queue
• hosting: self-hosted on AWS ECS/Fargate behind ALB
• binary data mode: database

Main question

Is there any known limitation or bug with EXECUTIONS_MODE=queue for the main instance when running behind AWS ALB / reverse proxy / ECS/Fargate, especially together with external task runners?

From our side, this currently looks like a bug or an unsupported edge case, because the exact same deployment works when the main instance is switched back to regular mode.