n8n-nodes-sixdee-redis

An n8n node for Redis that works the same against standalone, Sentinel and Cluster deployments, self-hosted or on AWS ElastiCache / MemoryDB.

n8n's built-in Redis node speaks to a single server with a handful of operations. This one covers 179 operations across 16 resources, plus a raw-command escape hatch for anything else — including module commands and commands added by newer Redis versions.

| | Built-in Redis node | This node | |---|---|---| | Standalone | yes | yes | | Sentinel | no | yes, with failover following | | Cluster | no | yes, with slot routing and fan-out | | AWS IAM auth | no | yes (ElastiCache + MemoryDB) | | Operations | ~7 | 179 + any raw command | | TTL | set-only | full: EX/PX/EXAT/PXAT/KEEPTTL, EXPIRE guards, per-field hash TTL |

Install

In the n8n UI: Settings → Community nodes → Install, then enter n8n-nodes-sixdee-redis.

Or from the command line:

cd ~/.n8n/nodes          # or $N8N_USER_FOLDER/nodes
npm install n8n-nodes-sixdee-redis
# restart n8n

From this repo:

cd n8n-nodes-sixdee-redis
npm install && npm run build && npm pack
cd ~/.n8n/nodes && npm install /path/to/n8n-nodes-sixdee-redis-1.0.0.tgz

Credentials

The credential has two independent choices: Provider (where it is hosted) and Deployment (the topology). Authentication is chosen separately again.

Deployment

| Topology | Fields | Notes | |---|---|---| | Standalone | Host, Port, Database | One endpoint. ElastiCache cluster-mode-disabled goes here — use the primary endpoint if you need to write. | | Cluster | Cluster Nodes, Read From | Seed nodes; the rest of the topology is discovered. ElastiCache cluster-mode-enabled, ElastiCache Serverless and MemoryDB all go here. | | Sentinel | Sentinel Nodes, Master Name, Connect To, Sentinel Password | The client asks Sentinel for the current master and follows failovers. Not used by AWS. |

Endpoints are comma-separated host:port. A bare host takes the default port (6379, or 26379 for Sentinel). IPv6 works bracketed: [::1]:7000.

Authentication

• Password / AUTH token — ACL username plus password. An ElastiCache AUTH token goes in the password field.
• AWS IAM — a short-lived SigV4 token, regenerated on every connection (and every 10 minutes on a trigger's long-lived connection, since the tokens expire after 15). Requires TLS; the node refuses to connect without it.
• None.

How far the AWS support is verified

There is no AWS account behind these tests, so be clear-eyed about what that means.

Verified offline, and strongly: the SigV4 signatures are cross-checked against AWS's own @smithy/signature-v4 and must match byte for byte — across ElastiCache and MemoryDB, long-term and STS credentials, Serverless, and values needing URI encoding. The signing-key derivation matches AWS's published vector. The credential chain is exercised against a local stand-in for the ECS task endpoint, and token refresh is checked to actually reach a live client's options on both standalone and cluster.

That rules out the failure most likely to bite — a well-formed token AWS rejects.

Not verified, and only a real account can: that ElastiCache accepts the token end to end (which also depends on the cache-side user being created in IAM mode), the TLS handshake against a real endpoint, cluster discovery through a configuration endpoint, and a reconnect crossing the 15-minute token lifetime. If you point a credential at a real cache and it fails, the error messages name the three usual causes directly.

AWS IAM setup

Three things have to line up, and the error messages call out each one:

1. Cache Name is the replication group ID, serverless cache name, or MemoryDB cluster name — not the endpoint hostname. The token is signed against this name.
2. User ID must be an ElastiCache/MemoryDB user created with the IAM authentication mode, and its user name must equal its user ID.
3. The signing principal needs elasticache:Connect (or memorydb:Connect) on that user's ARN.

Access keys come either from the credential or, with Environment / Instance Role, from AWS_* environment variables → ECS task role → EC2 instance role (IMDSv2) — resolved directly, with no AWS SDK dependency.

ElastiCache and MemoryDB are not reachable from the public internet: n8n has to run inside the VPC, or across a peering/VPN link.

Resources

String · get, set, setex, setnx, getset, getdel, getex, append, strlen, getrange, setrange, incr/decr (+by, +byfloat), mget, mset, lcs

Key & TTL · ttl, pttl, expiretime, pexpiretime, expire, pexpire, expireat, pexpireat, persist, exists, del, unlink, type, touch, rename, renamenx, copy, scan, keys, randomkey, object encoding/idletime/refcount, memory usage

Hash · hget, hgetall, hmget, hset, hsetnx, hdel, hexists, hlen, hkeys, hvals, hstrlen, hincrby, hincrbyfloat, hrandfield, hscan, hexpire, hpexpire, hexpireat, httl, hpttl, hpersist (per-field TTL, Redis 7.4+)

List · lpush, rpush, lpushx, rpushx, lpop, rpop, blpop, brpop, lrange, llen, lindex, lset, linsert, lrem, ltrim, lpos, lmove, rpoplpush

Set · sadd, srem, smembers, sismember, smismember, scard, spop, srandmember, smove, sunion/sinter/sdiff (+store), sintercard, sscan

Sorted Set · zadd, zrem, zscore, zmscore, zincrby, zcard, zcount, zrange, zrevrange, zrangebyscore, zrevrangebyscore, zrangebylex, zrank, zrevrank, zpopmin, zpopmax, zremrangebyscore, zremrangebyrank, zrandmember, zunionstore, zinterstore, zscan

Stream · xadd, xrange, xrevrange, xlen, xdel, xtrim, xread, xgroup create, xreadgroup, xack, xpending, xclaim, xinfo stream/groups

Pub/Sub · publish, spublish (sharded), pubsub channels, pubsub numsub

Bitmap · setbit, getbit, bitcount, bitpos, bitop HyperLogLog · pfadd, pfcount, pfmerge Geospatial · geoadd, geopos, geodist, geosearch JSON · json.set/get/del/arrappend/numincrby/objkeys (needs the ReJSON module)

Scripting · eval, evalsha, script load, fcall Server · ping, info, dbsize, time, config get/set, flushdb, client list, slowlog, memory stats Cluster · cluster info, nodes, slots, shards, keyslot, countkeysinslot

Raw Command · any command by name, and batches of commands as a pipeline or a MULTI/EXEC transaction.

TTL

TTL is handled in three places:

On write. Every Set carries an expiration option: EX seconds, PX milliseconds, EXAT/PXAT absolute timestamps, or Keep Existing TTL. This matters because a plain SET clears any TTL the key had — KEEPTTL is how you avoid that.

On the key. Set TTL (seconds/milliseconds), Expire At, Remove TTL, and reads via Get TTL / Get Expiry Timestamp. -1 means no TTL, -2 means no key. The NX/XX/GT/LT guards (Redis 7+) are exposed as Only Set When, so you can extend a TTL only when the new one is longer.

On hash fields. Redis 7.4 added per-field expiry — hexpire, httl, hpersist and friends are all here.

Get and Set Expiry (GETEX) reads a value and changes its TTL in one command, including removing it with PERSIST.

Cluster behaviour

Commands that are scoped to a single node — KEYS, SCAN, DBSIZE, INFO, FLUSHDB, CONFIG GET, PING — are fanned out across every master and merged: counts are summed, lists are concatenated, anything else is returned per node as { node, result }.

Multi-key commands only work when every key hashes to the same slot. Use a hash tag — the part in braces is what gets hashed, so user:{42}:name and user:{42}:email always land together. When they do not, Redis returns CROSSSLOT and the node explains the fix in the error.

SCAN iterates until the cursor wraps on each master, with a Max Keys cap to stop early. Prefer it over KEYS, which blocks the server for the whole scan.

Cluster mode supports database 0 only — the Database Number field is hidden for it, and ignored if set.

Raw commands

The typed resources do not and cannot cover everything, so Raw Command sends any command by name:

• FT.SEARCH idx:items "@price:[10 100]" — RediSearch
• TS.ADD temp 1691000000 22.5 — RedisTimeSeries
• anything a newer Redis version added

Arguments are comma-separated, or an array expression when an argument itself contains a comma. Cluster Routing controls whether it goes by key, to every master, or to one arbitrary node (for key-less commands).

Execute Many Commands takes [["SET","a","1"],["INCR","n"]] and runs it as a pipeline, or as an atomic MULTI/EXEC transaction.

Trigger node

SixDee Redis Trigger starts workflows from:

• Channel / Channel Pattern — pub/sub SUBSCRIBE / PSUBSCRIBE
• Sharded Channel — SSUBSCRIBE, cluster-only (Redis 7+)
• Keyspace Notification — key events such as expired or del. The server needs notify-keyspace-events configured; on ElastiCache and MemoryDB that is a parameter group setting, and it is off by default.

Error messages

Redis errors are translated into something actionable rather than passed through raw:

| Redis says | The node explains | |---|---| | CROSSSLOT | which keys are on different shards, and that a hash tag fixes it | | WRONGPASS under IAM | cache name vs endpoint, user ID mismatch, missing Connect permission | | READONLY | Sentinel role is set to replica, or you are on an ElastiCache reader endpoint | | OOM | at maxmemory with noeviction | | WRONGTYPE | the key holds a different type; check it with Get Type | | NOSCRIPT | load the script first | | Failed to refresh slots cache | node announce addresses, or an AWS security group blocking node ports | | connect timeout on AWS | ElastiCache is VPC-only; n8n must be inside it |

A wrong password reports WRONGPASS, not the generic "Connection is closed" that ioredis surfaces — the node keeps the first diagnostic error from the socket, since the useful one arrives before the connection gives up.

Verified against live Redis

Every operation is exercised against running servers, not mocked:

| Suite | Checks | |---|---| | All operations | 179/179, against cluster, standalone, Sentinel and redis-stack | | Cluster behaviour | fan-out, SCAN iteration, CROSSSLOT, argument construction | | Deployment modes | standalone, Sentinel master + replica, endpoint parsing, SigV4 signing | | Raw / batch | pipelines, MULTI/EXEC, per-item parameters, continueOnFail | | Trigger | all four modes across cluster, standalone and Sentinel | | Node structure | 2941 assertions on generated properties and templates | | AWS auth (npm run test:aws) | 22 checks — see below | | TLS (test:tls) | CA verification, self-signed rejection, SNI, auth over TLS | | Production (test:production) | connection lifecycle, scale, data integrity, concurrency | | Resilience (test:resilience) | OOM, restricted ACLs, command timeout, server restart | | Failover (test:failover) | Sentinel promotion, cluster node loss, 2000-message burst |

Run everything with npm run test:all (failover is excluded — it restarts containers; run npm run test:failover deliberately).

What the production suites establish

• No connection leaks. 40 successful, 20 failing and 10 unreachable executions each return the server to its baseline connection count. The node opens one client per execution, so this is the failure mode that would bite first.
• Scale. 1000 items in one execution in ~65ms; a 5MB value round-trips in ~33ms; SCAN sweeps 1000 keys across three masters in ~2ms; a 500-command pipeline in ~13ms.
• Data integrity. Unicode, embedded newlines and tabs, quotes and backslashes, empty strings, 100KB single lines and leading-zero numerics all round-trip byte for byte. Objects are stored as JSON and parsed back.
• Concurrency. 20 parallel executions lose no increments and leak no connections.
• Failure behaviour. An OOM write is rejected and explained; a restricted ACL user is denied with ACL-specific guidance; a slow command honours Command Timeout; a server restart resolves rather than hanging and a prolonged outage fails fast rather than blocking the workflow.
• Failover. Sentinel promotes a replica, and the node follows it with no credential change — master resolves to the promoted node, replica to the demoted one. A lost cluster master fails promptly rather than hanging, and the cluster recovers when it returns.
• Trigger throughput. 2000 published messages are all delivered, with no duplicates and none lost.

Cluster pub/sub has no global ordering guarantee. PUBLISH may enter at any node and reach subscribers over different cluster-bus paths, so messages can arrive out of sequence. Nothing is lost or duplicated — but if your workflow depends on order, carry a sequence number in the payload, or use a Stream.

Plus an end-to-end run inside n8n 2.41: an 18-step workflow across all four deployments, the credential Test button, and an activated pub/sub trigger workflow firing real executions.

Bugs that testing caught and fixed, worth knowing about if you extend this:

• Argument order. Redis interleaves keywords (XADD key MAXLEN 100 *, LINSERT key BEFORE pivot value, BITOP AND dest src), so operations declare an explicit argument template. A validator asserts every template emits every declared argument.
• SSUBSCRIBE through ioredis Cluster is unreliable — the promise intermittently never settles. Sharded channels are per-node anyway, so the trigger resolves each channel's slot owner and subscribes directly on it, one call per slot (Redis rejects a single SSUBSCRIBE spanning slots even on one node).
• A wrong Sentinel master name used to hang forever. Every connection attempt is now bounded by Connect Timeout, and Sentinel retries are capped.
• CLUSTER COUNTKEYSINSLOT only answers on the slot's owner and carries no key to route by, so it is fanned out and summed.
• EVAL/FCALL accept zero keys — the count is still sent (FCALL fn 0).

Notes

• Built on ioredis 5.x, the version n8n itself bundles.
• One connection per node execution, shared across all items and closed afterwards.
• Continue On Fail captures the error per item instead of failing the execution.
• The node is usableAsTool, so an AI Agent can call it.
• Credentials have a Test button that connects for real and reports the master count for a cluster.
• If your Sentinels do not require a password but your data nodes do, ioredis logs a harmless "server does not require a password" warning — the Sentinel Password field falls back to the Redis password by design.
• inputs/outputs use the literal 'main' rather than n8n's NodeConnectionTypes enum, which older n8n releases do not export. This keeps the node loadable across versions.

Development

npm install
npm run build        # tsc + copy icons
npm run dev          # tsc --watch

Test topologies live in the parent directory:

docker compose up -d                              # 3-node cluster, ports 7001-7003
docker compose -f docker-compose.sentinel.yml up -d   # standalone 6380, sentinel 26379-26381