Step by Step Guide in Securing Redis for n8n
Who this is for: DevOps engineers and platform admins deploying n8n in production who need to protect Redis traffic and enforce least‑privilege access. For a complete overview of Redis usage, errors, performance tuning, and scaling in n8n, check out our detailed guide on Redis for n8n Workflows.
Quick Analysis
- Enable TLS in
redis.conf(tls-port 6379,tls-cert-file,tls-key-file,tls-ca-cert-file). - Restrict network access – allow only the n8n host/IP via firewall (e.g.,
iptables -A INPUT -p tcp -s <n8n‑IP> --dport 6379 -j ACCEPT). - Create a dedicated ACL user for n8n (
ACL SETUSER n8n on >strongPassword ~* +@all). - Point n8n to the secured endpoint:
REDIS_URL=rediss://n8n:<password>@redis.example.com:6379. - Test with
redis-cli -h redis.example.com -p 6379 --tls -a <password>– you should seePING → PONG.
Result: All traffic between n8n and Redis is encrypted, only the n8n server can reach Redis, and n8n operates under a least‑privilege Redis user.
1. Why Securing Redis Matters for n8n
n8n uses Redis for the Queue and Cache layers. An exposed Redis instance can leak sensitive data or allow attackers to tamper with workflows. Dockerized Redis is the starting point. Complete the setup using this tutorial Docker Redis setup for n8n, then proceed with the next steps.
| Risk | Impact on n8n |
|---|---|
| Plain‑text traffic | Credentials and workflow data can be sniffed. |
| Open port (6379) | Anyone can read/write keys, hijack or delete workflows. |
Default default user |
Unlimited privileges – a single compromised key gives full control. |
Implementing TLS, firewall restrictions, and ACLs eliminates these vectors while preserving n8n performance.
2. Enabling TLS on Redis (Transport‑Level Encryption)
2.1 Prerequisites
| Item | Recommended version |
|---|---|
| Redis Server | 7.0+ (native TLS) |
| OpenSSL | 1.1.1+ |
| n8n | 0.226.0+ (supports rediss://) |
EEFA: Use certificates signed by an internal or trusted public CA in production. Self‑signed certs are acceptable for dev but require the client to supply the CA file.
2.2 Generate a Private CA (once per environment)
# Create CA key
openssl genrsa -out ca.key 4096
# Self‑sign CA certificate
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
-out ca.crt -subj "/CN=redis-ca"
2.3 Generate a Server Certificate
# Server key
openssl genrsa -out redis.key 4096
# CSR with the server’s FQDN
openssl req -new -key redis.key -out redis.csr \
-subj "/CN=redis.example.com"
2.4 Sign the Server Certificate with the CA
openssl x509 -req -in redis.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out redis.crt -days 730 -sha256 \
-extfile <(printf "[v3_req]\nsubjectAltName=DNS:redis.example.com")
EEFA: Secure redis.key (chmod 600) and keep the CA private key offline.
2.5 Configure TLS in redis.conf
tls-port 6379 port 0 # disable plain‑text listener tls-cert-file /etc/redis/redis.crt tls-key-file /etc/redis/redis.key tls-ca-cert-file /etc/redis/ca.crt tls-auth-clients no # set to "yes" for mutual TLS
Restart Redis to apply the changes:
systemctl restart redis-server
2.6 Verify TLS is Active
redis-cli -h redis.example.com -p 6379 --tls --cacert /path/to/ca.crt PING # Expected output: PONG
3. Locking Down Network Access (Firewall Rules)
3.1 Determine the n8n Host IP
curl ifconfig.me # run on the n8n server
Assume the IP is 203.0.113.42.
3.2 iptables Example (Linux)
iptables -F # flush existing rules (use cautiously) iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p tcp -s 203.0.113.42 --dport 6379 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP netfilter-persistent save # persist on Debian/Ubuntu
3.3 Cloud‑Provider Security Group (AWS)
| Rule | Type | Protocol | Port | Source |
|---|---|---|---|---|
| Allow TLS from n8n | Inbound | TCP | 6379 | 203.0.113.42/32 |
| Implicit deny | Inbound | TCP | 6379 | 0.0.0.0/0 |
EEFA: When n8n runs behind a load balancer, use the balancer’s private IP or security group as the source instead of a single host IP.
To get the best performance out of Redis, follow this optimization guide Optimizing Redis for n8n performance. After completing it, continue with the workflow below.
4. Configuring Redis ACLs for n8n (Application‑Level Authorization)
4.1 Create a Dedicated n8n User
redis-cli ACL SETUSER n8n on >StrongP@ssw0rd ~* +@all
| Flag | Meaning |
|---|---|
| on | Enable the user. |
| >StrongP@ssw0rd | Set password (hashed automatically). |
| ~* | Allow access to all keys (tighten to ~n8n:* if possible). |
| +@all | Grant all command categories (or restrict to +@read +@write). |
4.2 Verify the ACL Entry
redis-cli ACL LIST | grep n8n # Expected output: user n8n on >hashedpwd ~* +@all
4.3 Configure n8n to Use the Secure Redis Endpoint
Add the following to your n8n environment file (or Docker secrets):
REDIS_URL=rediss://n8n:StrongP%40ssw0rd@redis.example.com:6379
Note: The @ in the password is URL‑encoded as %40.
Docker Compose Example
services:
n8n:
image: n8nio/n8n
environment:
- REDIS_URL=rediss://n8n:${REDIS_PASSWORD}@redis.example.com:6379
EEFA: Store ${REDIS_PASSWORD} in Docker/K8s secrets or a vault—never commit it to source control.
5. End‑to‑End Validation
5.1 Test the Exact Connection String from the n8n Host
redis-cli -h redis.example.com -p 6379 --tls \
--user n8n --pass StrongP@ssw0rd PING
# Expected: PONG
5.2 Verify n8n Can Write to Redis
Run a simple n8n workflow that sets a key (e.g., “Set a key”). Then check the key from the CLI:
redis-cli -h redis.example.com -p 6379 --tls \
--user n8n --pass StrongP@ssw0rd GET n8n:test
# Should return the value written by the workflow.
5.3 Troubleshooting Matrix
| Symptom | Likely Cause | Fix |
|---|---|---|
| ECONNREFUSED | Firewall blocks n8n IP | Add the IP to iptables/SG allow rule |
| WRONGPASS | Password mismatch or missing URL‑encoding | Verify REDIS_URL and encode special characters |
| NOAUTH | ACL user not enabled | Re‑run ACL SETUSER n8n on … |
| TLS handshake failure | Missing or wrong CA file | Supply --cacert /path/to/ca.crt or correct tls-ca-cert-file |
6. Quick‑Start Checklist
| Checklist | Item |
|---|---|
| ✓ | TLS – tls-port set, certs in place, Redis restarted, redis-cli --tls PING succeeds. |
| ✓ | Firewall – Only n8n IP allowed on port 6379 (iptables or SG). |
| ✓ | ACL – n8n user created with password, key pattern limited if possible. |
| ✓ | n8n Config – REDIS_URL uses rediss:// scheme, password URL‑encoded. |
| ✓ | Test – CLI from n8n host succeeds; n8n workflow runs without errors. |
| ✓ | Monitoring – Enable alerts on failed auth attempts; consider tls-auth-clients yes for mutual TLS. |
7. Common Pitfalls & Remedies (EEFA)
| Pitfall | Why It Happens | Remedy |
|---|---|---|
| Self‑signed cert not trusted | Client omits --cacert. |
Provide the CA file or set tls-ca-cert-file correctly. |
| Port conflict (6379 vs 6380) | port 6379 left enabled alongside tls-port. |
Set port 0 to disable non‑TLS listener. |
Password contains @ or : |
URL parsing truncates the password. | URL‑encode (@ → %40, : → %3A). |
| ACL too permissive | Accidentally added +@admin. |
Restrict to +@read +@write and limit key pattern (~n8n:*). |
| Firewall rule order | Later generic allow overrides specific deny. | Place specific allow rules before any broader allow. |
| ACL changes lost after restart | Using a temporary config file. | Persist ACL lines in redis.conf (user n8n on …). |
Conclusion
Securing Redis for n8n requires a three‑layer approach:
- Transport encryption via native TLS ensures data in flight cannot be intercepted.
- Network segmentation (firewall or security groups) guarantees only the n8n host can reach the Redis port.
- Application‑level ACLs enforce the principle of least privilege, limiting what n8n can do inside Redis.
By applying these controls, you protect credentials, workflow state, and execution logs from exposure or tampering, while preserving the high‑performance characteristics that n8n expects from Redis. Implement the steps above in your production pipeline today to achieve a hardened, production‑ready deployment.
