Keycloak Self-hosted
You set up a keycloak self hosted server by running the app with a database. Then you add realms, users, and client rules so your team can log in. Many teams start by linking their main user directory and making broad admin groups. When those roles are too wide, one login gives too much power across systems. How a keycloak self hosted architecture manages identity Keycloak is an open source tool that manages user logins and identity tokens. When you run it yourself, you control the server, th
Keycloak + Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak self hosted server by running the app with a database. Then you add realms, users, and client rules so your team can log in. Many teams start by linking their main user directory and making broad admin groups. When those roles are too wide, one login gives too much power across systems.
How a keycloak self hosted architecture manages identity
Keycloak is an open source tool that manages user logins and identity tokens. When you run it yourself, you control the server, the database, and the network. The tool uses realms to keep different teams or apps apart from each other. Inside a realm, admins create users or sync them from an existing corporate directory.
Each app that needs login support registers as a client inside the realm. When a user tries to log in, the app sends them to the login screen. The server checks their password and asks for a second factor if rules require it. After the check passes, the server signs a token and sends it back.
That token holds data about the user, including their email and assigned roles. You can set up realm roles that apply across every app in that space. You can also set up client roles that apply to just one specific app. Groups let you bundle roles together and assign them to whole teams at once. Admins also set token life spans so users must log in again after a set time.
Planning storage and high availability for your server
Running your own identity server means you must keep it online at all times. If the login server goes down, your team cannot reach their daily work tools. A production setup needs a relational database to store realms, users, and role mappings. Using a local file store works for testing, but it fails under real load.
Teams usually run two or more server nodes behind a load balancer for uptime. The nodes share state through an internal cache so active logins stay valid everywhere. You also need valid TLS certificates so passwords and tokens stay safe on the wire. Regular database backups are vital because losing realm data locks out every user and app.
Keycloak + Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity servers solve and where runtime gaps remain
A self-hosted identity server solves the problem of scattered accounts and weak passwords. You get one place to turn off an account when a person leaves the team. You also get a clear log of who logged in and when they did it. Standard protocols like OIDC and SAML make it easy to link web apps.
Still, an identity provider only decides who can log in at the start. Once a developer gets into a database or server, the login tool steps back. It cannot see the SQL queries or shell commands the user runs next. A valid token does not stop someone from dropping a table by mistake.
Identity roles are also coarse when mapped to backend databases and cloud consoles. Many teams map a whole engineering group to a single shared database role. Everyone in that group then gets the same read and write rights on live data. Raw fields like emails, phone numbers, card numbers, and national IDs come back in full. To control what happens during a session, you need checks at the command level.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What do I need to run a keycloak self hosted setup in production?
You need a supported relational database, TLS certificates, and at least two server nodes. A load balancer sits in front to route traffic and handle node failures.
How does Keycloak handle permissions for databases and servers?
It puts role names inside the user token during the login flow. The target system must read those roles and decide what the user can do.
Can Keycloak mask sensitive data or block bad database queries?
No, it only handles the login step and issues identity tokens to users. It does not inspect live queries or rewrite emails and card numbers in results.