Azure Cache for Redis
Azure-managed Redis — Access keys blade, TLS port 6380 vs 6379, Basic tier no SLA.
Azure Cache for Redis spans Basic → Enterprise. New caches expect TLS.
drivers.store.kv stays redis.
The one rule
Build rediss:// from Overview hostname + Access keys primary key + SSL port 6380. Do
not use 6379 unless you explicitly allowed non-TLS.
Find credentials (current portal)
- Azure Portal → your Azure Cache for Redis resource.
- Overview → copy Host name (
….redis.cache.windows.net). - Settings → Authentication → Access keys tab (or Overview → Show access keys) → copy Primary key.
- Ports: Overview link next to Ports, or docs defaults — 6380 TLS, 6379 non-TLS (disabled by default on new caches).
- Enterprise tiers may use port 10000 — check Overview for that SKU.
REDIS_URL=rediss://:PRIMARY_KEY@my-cache.redis.cache.windows.net:6380Azure's “connection string” blade often shows StackExchange-style
host:6380,password=…,ssl=True — translate that to rediss://:password@host:6380 for
oke.
Production guidance
| Tier | Notes |
|---|---|
| Basic | Shared, no SLA — not for production |
| Standard | Replicated |
| Premium / Enterprise | Clustering, persistence, VNet |
Non-TLS: Settings → Advanced settings → Allow access only via SSL = No — avoid in
production. Entra ID auth exists on newer tiers; oke's URL driver expects access-key
auth in REDIS_URL.
Real gotcha — port 6380 vs 6379
Using redis://…:6379 against a TLS-only cache fails. New caches disable non-TLS;
always start from 6380 + rediss:// unless you intentionally opened 6379.
Troubleshooting
TLS-only cache. Switch to port 6380 and rediss://. Confirm Advanced settings still
require SSL.
Primary key rotated or secondary key pasted by mistake. Re-copy Primary from
Authentication → Access keys and update REDIS_URL (empty username, key as
password).