Apache 2.0 · Open Source
Keycloak on Redis. Without the JGroups tax.
Locke is a drop-in Keycloak distribution that moves the realm, user, and authorization caches off embedded Infinispan onto Redis. Same admin console, same database, one switch (KC_CACHE=redis).
What is Locke
Stock Keycloak, with a Redis cache backend.
Locke is the upstream Keycloak codebase plus one thing: a Redis cache backend behind a single switch. Same SPIs, same admin console, same database schema. Flip it back and you have ordinary Keycloak.
Drop-in
Flip KC_CACHE=infinispan|redis at boot. No code changes, no migration.
Apache 2.0
Fully open source: stock Keycloak plus a Redis cache backend, nothing locked away.
Bring your own Redis
Works with any managed Redis. Colocated or external performs the same.
No JGroups to operate
No cluster discovery, split-brain handling, or state transfer. Redis coordinates.
The benchmark
Same throughput. Dramatically better failure behavior.
A 3-pod production cluster, head to head. Throughput is a tie. The difference shows up the moment a node dies.
| Load (logins/sec) | Stock / Infinispan | Locke / Redis | Parity |
|---|---|---|---|
| 80 | 274 req/s | 274 req/s | 100% |
| 160 | 548 req/s | 548 req/s | 100% |
| 250 | 856 req/s | 856 req/s | 100% |
p99 login latency when a node is lost (lower is better)
Bars use a compressed scale to keep Locke visible; the gap is ~15-34x. When an Infinispan node dies, the cluster stalls on a JGroups rebalance and state transfer. Locke keeps serving from Redis.
3-pod cluster, Keycloak 26.6.1, start --optimized, keycloak-benchmark Gatling AuthorizationCode flow. Full methodology in the report.
Why it matters
Built for the operators on call.
Resilience
A lost node is a sub-second blip, not a 31-second JGroups rebalance stall that hangs authentication mid-incident.
Upgrades
Cross-version rolling upgrades run under load with no JGroups protocol version to keep compatible across pods. No mixed-version outage window.
Operations
Point Keycloak at the managed Redis you already run and monitor. No JGroups discovery, no state transfer, one less distributed system to operate.
Quick start
One image. One switch.
Run the Locke image in production mode and point it at your Redis.
docker run ghcr.io/sky-cloak/locke:latest start --optimized
# Switch the cache backend to Redis
KC_CACHE=redis
KC_CACHE_REDIS_URL=redis://your-redis:6379
The honest part
An honest trade. Moving local caches to Redis adds a few milliseconds of read latency at moderate load (both stay under 170ms p99 to 250 logins/sec). And Redis does not raise Keycloak's realm-count ceiling. That limit is database-bound, not cache-bound. We benchmark these things and say so.
Run Keycloak on the cache you already operate.
Open source, Apache 2.0, benchmarked in production mode.