n8n redis node: The Five Operations That Work, the One That Is Misleading, and How to Avoid Cache Staleness

The headline answer to “n8n redis node” is: drop the node into a workflow, point it at a Redis instance, pick an operation, and pass the key. That is the surface. The honest version covers the five operations that work the way Redis docs describe them, the one operation that is a Lua script in disguise and behaves subtly differently than the docs suggest, the TTL behavior that silently expires your cached data, and the connection pattern that survives a real production deploy.

Table of contents

• Table of contents
• The direct answer
• The five operations that work as expected
• The one operation that is misleading: “List”
• The TTL behavior that quietly expires your cache
• The connection pattern that survives a real deploy
• The seven patterns teams actually use
• The failure modes that show up at scale
• FAQ
• FAQ

The short version for most n8n users: use the Redis node for set/get/incr/del/hget on cache keys. Treat the “List” operation with suspicion — it is KEYS * under the hood and will block your Redis on a large database. Always set TTLs explicitly; the default of no-TTL is rarely what you want for cache data.

Table of contents

• The direct answer
• The five operations that work as expected
• The one operation that is misleading: “List”
• The TTL behavior that quietly expires your cache
• The connection pattern that survives a real deploy
• The seven patterns teams actually use
• The failure modes that show up at scale
• FAQ

The direct answer

The minimum useful workflow:

1. Add a Redis node.
2. Pick the operation: set, get, delete, incr, hset/hget.
3. Enter the host, port, and password.
4. Pass the key as {{ $json.cacheKey }} or a literal string.
5. Set a TTL.

The five operations you should reach for first: set (write a value), get (read it back), delete (remove it), incr (atomic counter for rate-limiting or unique IDs), and the hash operations (hset, hget, hgetall) for structured data.

The five operations that work as expected

set — writes a key. In n8n, pass the key as a string and the value as a string. The node sends SET key value over RESP. There is no upsert flag; SET is always overwrite. For numbers, Redis stores them as strings; the n8n node does not type-coerce, so SET counter 5 and GET counter returns "5" as a string.

get — reads a key. Returns the value as a string. For numbers, you must parse the string in a downstream node (Number() in a Function node, or parseInt() in a Code node). For JSON, you must JSON.parse() the result.

delete — removes a key. Returns 1 if the key existed, 0 if not. In n8n, the node returns the integer directly.

incr — atomic increment. Returns the new value as a string. Use this for rate-limiting counters, idempotency keys, or unique-ID generation. The atomicity matters: two concurrent n8n workflows calling INCR on the same key get sequential values, not the same value.

hset / hget / hgetall — hash operations. hset key field value writes a field on a hash. hget key field reads one field. hgetall key returns the entire hash as an object. Use hashes when you want structured data without the serialization cost of JSON.

These five are the n8n-Redis workhorses. Everything else is rarer.

The one operation that is misleading: “List”

The List operation in the n8n Redis node is KEYS <pattern>. KEYS in Redis is not what most people expect. From the Redis docs:

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases.

The n8n node exposes this operation without that warning. The pattern defaults to *, which scans every key in the database. On a database with 10 million keys, KEYS * blocks Redis for seconds and may cause cascading failures.

The right primitive for “find keys matching a pattern” is SCAN, which iterates without blocking. n8n’s Redis node does not expose SCAN directly. Workaround: use the Function node with ioredis or node-redis and call scanStream instead.

If you must use the List operation, restrict the pattern to a prefix (cache:user:*, not *) and limit the result size. On a small Redis instance with thousands of keys, KEYS is fine. On a production instance with millions of keys, it is a foot-gun.

The TTL behavior that quietly expires your cache

The Redis node’s set operation has a TTL field. The default is empty, which means no TTL — the key persists forever.

Most teams want TTLs on cache data. The failure mode: a workflow sets a key without a TTL, the key lives forever, the cache grows unbounded, the Redis instance fills up. Then the team notices when Redis OOMs and crashes.

The fix:

• Set TTLs explicitly. 5 minutes for ephemeral caches, 1 hour for short-lived session data, 24 hours for long-lived references.
• Use a single source of truth for TTL values. A Function node that returns {ttl: 300} based on the cache type.
• For keys that genuinely should not expire (counter, idempotency key), set them deliberately without a TTL.

The Redis node’s TTL field accepts an integer in seconds. There is no flag for “no TTL” beyond leaving it empty.

The connection pattern that survives a real deploy

Three things to get right:

1. Use a credential, not hardcoded values. The Redis node has a “Credentials” section. Set up a Redis credential with the host, port, password, and database number. Reference the credential in each node. Never inline the connection details in the workflow JSON.

2. Use a separate Redis instance for cache and for state. Cache data and state data have different access patterns and different TTL needs. A shared instance makes both harder to reason about. Use Redis logical databases (the db parameter, 0-15) or separate Redis instances.

3. Use a managed Redis in production. Self-hosted Redis on the same machine as your n8n instance is a single point of failure. A managed Redis (Upstash, Redis Cloud, ElastiCache) survives a machine restart and offers replication.

For n8n itself, the connection details come from the n8n configuration, not the workflow. The Redis credentials are scoped to the workflow. The pattern: one credential per environment (dev, staging, prod), the right one selected by the workflow’s environment variable.

The seven patterns teams actually use

1. API response caching. SET cache:endpoint:<hash> <response> EX 300. Read on miss, write on hit. Saves API quota and reduces latency.

2. Rate-limiting counter. INCR ratelimit:user:<id> EX 60. Read the counter; if over the limit, reject. Atomic, fast, no extra Redis calls.

3. Idempotency key. SET idemp:<key> <request_id> EX 86400 NX. The NX flag sets only if the key does not exist; returns nil if the key already exists. Use this to dedupe webhook deliveries.

4. Session data. SET session:<id> <json> EX 3600. Read on every request. Refresh on activity. Set TTL on logout.

5. Distributed lock. SET lock:<resource> <owner> EX 30 NX. Acquire; if nil, lock is held by someone else. Release with a Lua script that checks the owner. Use this to serialize critical sections across n8n workflows.

6. Leaderboard / sorted set. ZADD leaderboard <score> <member> and ZREVRANGE leaderboard 0 9 WITHSCORES. Sorted sets are not exposed in the n8n Redis node UI; use a Code node with ioredis.

7. Pub/sub between workflows. PUBLISH channel message from one workflow, SUBSCRIBE channel from another. Use this for cross-workflow signaling.

All seven are supported by the Redis node, but the last two require a Code node, not the UI node.

The failure modes that show up at scale

Connection limit. A workflow that calls Redis on every run, with high concurrency, can exhaust Redis’s maxclients. Fix: use a connection pool in the Redis client (most do this by default), or reduce workflow concurrency.

Memory exhaustion. Cache keys without TTLs fill Redis until it OOMs. Fix: always set TTLs; monitor used_memory; set maxmemory-policy allkeys-lru so Redis evicts old keys instead of refusing writes.

Hot keys. A single key receiving thousands of requests per second becomes a single-threaded bottleneck. Redis is single-threaded for command execution. Fix: shard the key (cache:user:1 -> cache:user:1:shard:<n>) or use Redis Cluster.

Stale data after invalidation. A workflow reads from cache, the underlying data changes, the cache is not invalidated. The next workflow run reads stale data. Fix: always invalidate cache on write, or use a short TTL (1-5 minutes) so staleness is bounded.

If you are running an n8n workflow against a Redis instance as part of a production automation, the cache pattern is the highest-value use case but also the most failure-prone. Run the workflow with explicit TTLs, use a managed Redis, and treat KEYS * as a debugging tool, not a workflow primitive.

For an n8n deployment that is hosted alongside the Redis it talks to, RunxBuild’s backend services can host both as separate deployable components on the same platform. The Redis connection string is in the n8n environment; the Redis itself is a managed database. For what running that stack at production scale costs, the RunxBuild hosting calculator gives you the per-month number.

FAQ

What Redis operations does the n8n Redis node support?

The UI exposes set, get, delete, incr, hset, hget, hgetall, lpush, rpush, lpop, rpop, lrange, sadd, smembers, srem, and List (KEYS). Anything more exotic requires a Code node with ioredis.

Why does my workflow show a connection error on first run?

The Redis credential is misconfigured. Check host, port, password, and database number. Verify with redis-cli -h <host> -p <port> -a <password> ping from a terminal.

How do I use Redis as a cache in n8n?

SET cache:<key> <value> EX <ttl_seconds> on first hit; GET cache:<key> on subsequent hits; DELETE cache:<key> on invalidation. The Redis node supports all three operations.

Can the Redis node do pub/sub?

Not via the UI node. Use a Code node with ioredis to call publish and subscribe. The UI node is for synchronous request-response operations.

Why is my cache key disappearing?

You forgot to set a TTL. The default is no-TTL, but most cache patterns want a TTL. Set EX <seconds> on every set.

How do I monitor Redis from n8n?

The simplest path: a periodic workflow that runs INFO memory and INFO stats and pushes the result to a dashboard. The Redis node’s get operation can call INFO if you set the key to a literal INFO command — but that requires raw command support, which the UI node does not expose. Use a Code node.

What is the difference between set and setnx?

SET key value overwrites unconditionally. SET key value NX overwrites only if the key does not exist (returns nil if it does). Use NX for idempotency keys and distributed locks.

Can I use Redis Cluster with the n8n Redis node?

The UI node does not support Cluster mode. Use a Code node with ioredis configured for Cluster. Most teams do not need Cluster until they have >25 GB of data or >100k operations/second.

FAQ

What Redis operations does the n8n Redis node support?

The UI exposes set, get, delete, incr, hset, hget, hgetall, lpush/rpush/lpop/rpop/lrange, sadd/smembers/srem, and List (KEYS). Anything more exotic requires a Code node.

Why does my workflow show a connection error on first run?

The Redis credential is misconfigured. Check host, port, password, and database number. Verify with redis-cli ping.

How do I use Redis as a cache in n8n?

SET cache:<key> <value> EX <ttl> on first hit; GET cache:<key> on subsequent hits; DELETE cache:<key> on invalidation.

Can the Redis node do pub/sub?

Not via the UI node. Use a Code node with ioredis to call publish and subscribe.

Why is my cache key disappearing?

You forgot to set a TTL. The default is no-TTL, but most cache patterns want a TTL. Set EX <seconds> on every set.

How do I monitor Redis from n8n?

A periodic workflow that runs INFO memory and INFO stats and pushes the result to a dashboard. The UI node does not expose raw commands — use a Code node.

What is the difference between set and setnx?

SET key value overwrites unconditionally. SET key value NX overwrites only if the key does not exist. Use NX for idempotency keys and locks.

Can I use Redis Cluster with the n8n Redis node?

The UI node does not support Cluster mode. Use a Code node with ioredis configured for Cluster.