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