n8n worker setup failing with Coolify hosting - jobs not queuing properly

I have n8n running on Coolify but can’t get the worker mode to function correctly. I set up everything based on the Docker documentation but workflows keep running on the main container instead of being distributed to workers.

The main issues I’m seeing are:

  • When I trigger a workflow the loading indicator gets stuck and only stops when I reload the page.
  • Workers don’t seem to pick up any jobs from the queue.
  • Redis container shows no activity in logs.

Here’s my docker compose setup:

services:
  automation-server:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - SERVICE_FQDN_N8N_5678
      - 'N8N_EDITOR_BASE_URL=${SERVICE_FQDN_N8N}'
      - 'WEBHOOK_URL=${SERVICE_FQDN_N8N}'
      - 'GENERIC_TIMEZONE=${GENERIC_TIMEZONE:-Europe/Berlin}'
      - DB_TYPE=postgresdb
      - 'DB_POSTGRESDB_DATABASE=${POSTGRES_DB:-automation}'
      - DB_POSTGRESDB_HOST=database
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_USER=$SERVICE_USER_POSTGRES
      - DB_POSTGRESDB_PASSWORD=$SERVICE_PASSWORD_POSTGRES
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=cache
      - QUEUE_BULL_REDIS_PORT=6379
      - QUEUE_MODE=redis
      - N8N_RUNNERS_ENABLED=true
      - QUEUE_HEALTH_CHECK_ACTIVE=true
      - N8N_LOG_LEVEL=debug
    volumes:
      - 'app-data:/home/node/.n8n'
    command: start
    depends_on:
      - database
      - cache

  worker-node:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - 'GENERIC_TIMEZONE=${GENERIC_TIMEZONE:-Europe/Berlin}'
      - DB_TYPE=postgresdb
      - 'DB_POSTGRESDB_DATABASE=${POSTGRES_DB:-automation}'
      - DB_POSTGRESDB_HOST=database
      - DB_POSTGRESDB_USER=$SERVICE_USER_POSTGRES
      - DB_POSTGRESDB_PASSWORD=$SERVICE_PASSWORD_POSTGRES
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=cache
      - QUEUE_BULL_REDIS_PORT=6379
      - QUEUE_MODE=redis
      - N8N_WORKER=true
      - N8N_LOG_LEVEL=debug
    volumes:
      - 'app-data:/home/node/.n8n'
    command: worker
    depends_on:
      - database
      - cache
  
  database:
    image: 'postgres:16-alpine'
    volumes:
      - 'db-data:/var/lib/postgresql/data'
    environment:
      - POSTGRES_USER=$SERVICE_USER_POSTGRES
      - POSTGRES_PASSWORD=$SERVICE_PASSWORD_POSTGRES
      - 'POSTGRES_DB=${POSTGRES_DB:-automation}'

  cache:
    image: redis:7
    volumes:
      - cache_storage:/data

The main container logs show queue mode is active but workers stay completely silent. Could this be related to Coolify’s networking setup or am I missing something in the configuration? Anyone got this working with Coolify before?

Your config looks mostly right, but you’re missing a key piece - the database port for your worker. Add DB_POSTGRESDB_PORT=5432 to your worker environment variables. Without it, the worker can’t connect to the database properly even though it seems to start fine. I hit the same issue with silent workers on my Coolify setup last month. Redis was working but workers weren’t registering with the queue because of incomplete database connectivity. Once I added the missing port variable, workers immediately started picking up jobs and the UI loading problems vanished. Also, check your Coolify logs at the service level, not just container logs - network connectivity warnings sometimes only show up there. The networking in Coolify shouldn’t mess with inter-container communication since everything runs on the same Docker network by default.

Check if your worker container’s actually running - do docker logs worker-node to see startup errors. I had the same thing happen when my worker kept crashing from missing env vars, but the container just silently restarted. Try adding QUEUE_BULL_REDIS_PASSWORD= (leave it empty) to both containers - some redis setups need it explicitly set even without a password. Weird that your redis logs are quiet though, you should at least see connection attempts.

Dealt with this same headache for weeks! Your config looks fine - the real problem is how Coolify handles variable substitution timing between your main app and worker containers. Your worker probably can’t connect to Redis on startup because of this timing issue. Here’s what fixed it for me: hardcode the Redis host as cache in both containers instead of using the QUEUE_BULL_REDIS_HOST variable, and throw in QUEUE_BULL_REDIS_DB=0 explicitly on both services. Also run docker ps to see if your worker’s actually staying up - mine was silently restarting every few seconds from connection failures. That stuck loading indicator? Your main container’s waiting for worker confirmation that’s never coming. I added QUEUE_RECOVERY_INTERVAL=60 which helped me spot when jobs were getting orphaned during troubleshooting.

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.