Keycloak Cluster
You build a keycloak cluster by running several nodes behind a load balancer. Each node reads from one shared database and syncs memory caches across the network. Teams set up this layout so login checks stay online when a server fails. Yet many admins grant broad admin roles across realms to save time during setup. Those wide roles let one leaked token change settings or read user data anywhere. How a keycloak cluster works in production A single identity server becomes a bottleneck when man
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a keycloak cluster by running several nodes behind a load balancer. Each node reads from one shared database and syncs memory caches across the network. Teams set up this layout so login checks stay online when a server fails. Yet many admins grant broad admin roles across realms to save time during setup. Those wide roles let one leaked token change settings or read user data anywhere.
How a keycloak cluster works in production
A single identity server becomes a bottleneck when many users log in at once. If that one server restarts for updates, no one can log into your apps. Running a keycloak cluster fixes this problem by spreading traffic across multiple active nodes. A load balancer sits in front and sends each user request to a healthy node.
Every node in the group talks to the same central relational database. This database holds persistent data like realm rules, user profiles, and role mappings. Nodes do not write every login token to the disk database right away. Disk writes take too much time when thousands of people log in together.
Instead, the servers use an in-memory cache layer to share active user sessions. When a user logs into node one, that node stores the session in memory. It also copies that session state to a peer node over the local network. If node one goes down, node two already has the user session ready. The user stays logged in and does not see an error screen.
Nodes find each other on the network using a discovery protocol. In cloud setups, nodes check DNS records or container labels to build the group. When a new node starts up, it joins the ring and syncs cache state. When a node stops, the remaining servers rebalance the session cache on their own.
Why realm roles and group rules need tight limits
Setting up high uptime for logins is only half of the security job. You also have to control what logged-in engineers can do inside your systems. Identity servers group users into realms, client roles, and team groups. When a user logs in, the server puts those role names inside a token.
Apps and tools read that token to decide if the user may enter. During a fast rollout, teams often assign coarse roles to whole engineering groups. Every developer might get the same database role or server group claim. This makes the initial setup fast, but it creates a huge blind spot later.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If an engineer has a production role, that role stays active all day. The identity cluster checks who the person is at the moment they log in. After that check passes, the user talks straight to the database or server.
What native identity clustering leaves open at runtime
A redundant login service keeps your sign-in page up and running all year. It proves who a user is and hands out signed tokens fast. Still, an identity server only acts at the start of a user session. It decides who can log in, not what commands they run after that.
Once an engineer opens a database session, the identity server steps out of the way. It cannot see the SQL queries or shell commands running over that link. It cannot stop a bad update query or pause a dangerous delete command. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results.
Auditors often ask who ran a specific query on a production table last week. Your identity logs only show that an engineer got a valid token at nine. They do not show the fifty queries that person ran before lunch. To close this gap, teams need runtime controls that inspect every single command in flight.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How many nodes should a keycloak cluster have?
Most production teams run at least two or three nodes across separate zones. This setup keeps logins working if one server or data center zone fails.
Do cluster nodes need sticky sessions on the load balancer?
Sticky sessions are helpful because they send a user back to the same node. This cuts down on network chatter, though cache sync still handles node failures.
How do you update a keycloak cluster without downtime?
Teams often drain traffic from one node at a time or switch between two groups. Always check that database changes work with both old and new node versions first.