Redis Caching

The ConnectWise PSA node supports optional Redis caching on any GET operation. When enabled, responses are stored in Redis and served from cache on subsequent requests, reducing API calls and speeding up workflows that hit the same endpoints repeatedly.

Environment Variables

If Redis is running on localhost:6379 with no password (the defaults), you don’t need to set any environment variables — the node connects automatically.

For non-default setups, the node reads n8n’s existing Redis env vars. These variables are normally associated with n8n’s queue mode (where Redis handles distributing executions across workers), but you don’t need to be running queue mode to use them. Just set the variables and the node will connect to Redis for caching independently:

The node always uses DB 1, keeping cache data separate from n8n’s default DB 0 queue data.

How to Enable It

1. Run a Redis instance (Docker is easiest — see Docker Setup below)
2. In the node UI on any GET operation, toggle Cache Response and set a duration (e.g. 5m, 1h, 300)

If Redis is running on localhost:6379 with no password (the default), no environment variables are needed — it just works. Only set the env vars above if your Redis instance is on a different host, port, or requires a password.

Cached responses are served automatically on subsequent executions until the TTL expires.

Graceful Failover

The caching layer is designed to never break a workflow if Redis is unavailable:

• Lazy connect — Redis connection isn’t attempted until the first cache operation. If nobody enables caching, Redis is never touched.
• No retries — retryStrategy: () => null. If Redis is down, it fails immediately instead of blocking the workflow with retry loops.
• Offline queue disabled — Commands aren’t queued when disconnected; they return null.
• 1-second timeout — Connection attempt gives up after 1 second.
• Graceful null returns — getCached() returns {data: null} on any error. setCached() returns {success: false}. The API request proceeds normally as if caching doesn’t exist.
• Dead connection recovery — Tracks lastConnectionError. If the client dies, it disconnects and recreates it on the next attempt (self-healing).
• Error hints, not exceptions — Cache failures surface as execution hints in the n8n UI (e.g. cache_error) rather than throwing errors that would stop the workflow.

In short: Redis down = cache miss. The workflow always completes. Users see a hint that caching failed, but their data still comes through from the API.

Docker Setup

For users running n8n in Docker, add Redis to your docker-compose.yml:

services:
  redis:
    image: redis:7-alpine
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5

  n8n:
    # ... existing n8n config ...
    environment:
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
    depends_on:
      redis:
        condition: service_healthy

volumes:
  redis-data:

For users running n8n without Docker, install Redis locally (sudo apt install redis-server or brew install redis) and the defaults (localhost:6379, no password) work out of the box with no env vars needed.