What a Keycloak implementation involves
A self-managed Keycloak rollout starts with an inventory of what the identity service has to serve, not with installation. List every application that will sign users in, the protocol each one speaks (OpenID Connect, OAuth 2.0 or SAML 2.0), the user populations behind them, and any directory that already holds accounts, such as LDAP or Active Directory. That inventory drives the realm and client design: how many realms exist, which clients are confidential or public, which roles and groups map to application permissions, and where token and session lifetimes differ by application.
The infrastructure decisions follow from that design. Your team chooses the database Keycloak will use from the supported list in the Keycloak database guide, sets the high availability architecture, and decides how the admin console and Administration REST API are reached separately from public frontend URLs. Each of these choices changes the build sequence. For example, a multi-site design needs a synchronously replicated database before anything else is tested, and the team should confirm which HA design is supported for its chosen database and hosting model before committing to it.
Triggers for the work vary. Organizations usually start when they retire a hosted identity service, when they want to consolidate sign-in for many applications behind one provider, or when they move off an older Keycloak release that is no longer a sensible base. Each trigger brings a different starting point: a hosted service may require password hash handling and client cutover, while an older Keycloak may require a version path. Plan environments (development, test, pre-production and production), a go-live checklist, and a rollback plan before the first realm is created.
Whether to build in-house or bring in a partner depends largely on your team's identity and platform skills. Staff who already run OIDC and SAML integrations, manage Kubernetes or VM-based clusters, and own database operations can carry much of the work. Where those skills are thin, the scope inventory, realm design and HA testing are the areas to outsource first. Ask any partner to show how the fixed scope covers environments, go-live support and knowledge transfer to your operators.
What the work includes
A fixed-scope Keycloak rollout usually runs as six work packages, each ending in a deliverable you keep. The scope, owners and sign-off points are agreed in writing before build work starts.
Discovery and application inventory
Workshops and a review of current sign-in paths identify each application, its protocol (OpenID Connect, OAuth 2.0 or SAML 2.0), its user population and the directory it reads from. Owners, redirect URIs and the first-phase scope are confirmed in writing. Check that every application has a named owner before design starts. Deliverable: an application inventory and scope document.
Architecture and environment design
This package sets the database engine and version, the high availability architecture, the separate hostnames for the admin console and public frontend URLs, and how development, test and production differ. Each decision is recorded with its trade-off so the internal team can revisit it later. Confirm the database platform and availability target with your own teams first. Deliverable: architecture design document and environment map.
Deployment on your platform
Keycloak is installed in your cloud account, data center or cluster using the agreed method, such as the Keycloak Operator on Kubernetes. The package covers TLS, the reverse proxy path rules, and metrics enablement on the management interface. Ask which operator update approval mode will be configured. Deliverable: deployment code or manifests, pipeline definitions and a per-environment configuration record.
Baseline realm and security configuration
Realm structure, password and brute force policies, token and session lifetimes, admin access, event logging and outbound email settings are configured once as a common baseline. Settings are chosen against your own policy, and each choice is documented for later audit evidence. Deliverable: exported realm configuration, a security settings record and a control mapping that your compliance team can review.
Integration of the first applications
The applications agreed in discovery are registered as OpenID Connect or SAML 2.0 clients, with role and group mappings and token claims set for each one. Sign-in, sign-out and token refresh are tested per application in the non-production environments. Deliverable: client configurations, test results and onboarding notes for each application.
Cutover and handover
The package covers the go-live sequence, a rollback plan for each application, and a runbook covering routine operation and incident steps. Operators from your team are trained on the running system before handover. Support after go-live is a separate agreement, so confirm its terms in the quote. Deliverable: cutover plan, runbook and a handover record.
What drives cost and duration
This table lists the factors that change Keycloak implementation effort and schedule, why each one moves the work, and how to keep it manageable.
| Driver | Why it moves the effort | How to keep it down |
|---|---|---|
| Applications and clients | Each client needs redirect URIs, scopes, token settings and sign-in testing, so effort grows with every application onboarded. | Group applications by shared pattern, use a standard client template and onboard in waves. |
| Realms and their structure | Each realm carries its own clients, roles, authentication flows and keys, which multiplies configuration and test work. | Keep one realm where trust boundaries allow, and document the reason for each additional realm. |
| Directory sources and brokering | LDAP or Active Directory federation, attribute mappers and external identity providers each add mapping, synchronization and login-flow design. | Confirm the source of truth for each identity early and map only the attributes applications need. |
| HA architecture and database | Both supported HA designs need a synchronously replicated database, and failover testing adds load balancer, session and infrastructure work. | Choose one HA design before the build, confirm your database is on the supported list, and test failover in staging. |
| Environments and deployment platform | Each environment needs its own installation, configuration promotion and tests, and the platform choice sets the build and operations work. | Manage realm and client configuration as code and keep non-production topology close to production. |
| MFA and authentication policy | OTP, WebAuthn, passkeys, recovery codes and conditional flows each need policy design, user enrollment and help desk procedures. | Approve a short list of factors and provide one enrollment path for all users. |
| Custom themes and extensions | Login themes, custom flows and SPI extensions are code that must be rebuilt, tested and reviewed at every Keycloak upgrade. | Prefer built-in flows and standard theming, and keep each extension small, owned and documented. |
| Compliance evidence requirements | Assessors may ask for configuration records, access reviews, event logs and change history, which need collection and retention design. Independent auditors issue any report or certification. | Agree the control list and evidence format before the build and export configuration from the first environment. |
| Internal staff availability | Identity owners, application owners and network teams must answer design questions, approve changes and test sign-in, and delays there extend the schedule. | Name an owner for each application and directory before kickoff and book test windows in writing. |
Project phases and outputs
The seven phases move a Keycloak rollout from agreed requirements to a supported production service, with each phase closing decisions the next one depends on.
Run discovery and inventory applications
The DeployOpen team and your identity and application owners inventory every application, protocol (OpenID Connect, OAuth 2.0, SAML 2.0), user source, realm plan, directory integration and hosting location. The output is a written requirements and scope document. The phase closes when owners sign off on the application list and the realm and directory decisions that set the rest of the plan.
Design architecture and environments
The team designs the target topology: database engine and replication, high availability model, reverse proxy and hostname separation for the admin console, TLS, networking, backups, monitoring and environment layout. The output is an architecture decision record and an environment plan. The phase closes when the database, high availability design and deployment method (Operator or other) are approved by your infrastructure and security owners.
Build the non-production environment
DeployOpen builds the Keycloak deployment in a non-production environment inside your infrastructure, with realms, base authentication flows, password and MFA policies and the agreed directory connection in place. The output is a working environment with installation and configuration documented. The phase closes when a platform test confirms sign-in, token issuance and admin access behave as the design specifies.
Integrate a pilot application
One representative application is registered as a client and connected to the non-production Keycloak, including role and group mapping and token and session settings. The output is a tested integration and a repeatable client registration pattern for the remaining applications. The phase closes when the application owner and identity team agree the pattern and the claims the application needs.
Test and harden the platform
The team runs functional, failover and load tests against the design targets, reviews the hardening settings (brute force protection, token lifetimes, event logging, admin separation) and confirms metrics and alerts. The output is a test report, a hardening checklist and a list of accepted risks. The phase closes when open findings are fixed or formally accepted by the named risk owner.
Cut over to production
The production environment is built from the same tested configuration, applications are migrated or connected in an agreed order, and the cutover plan with rollback steps is executed in a change window you approve. The output is a live production service and a cutover record. The phase closes when sign-in is confirmed for each migrated application and the rollback option is retired or formally held.
Hand over and provide go-live support
DeployOpen delivers runbooks, configuration documentation, operator and upgrade procedures and training for your operators, then provides support during the agreed go-live period. The output is a handover package and a named support model for after go-live. The phase closes when your team accepts the handover in writing and the ongoing support arrangement is agreed. Ask for phase durations in the written scope.
What teams keep in-house and what they outsource
This table shows who usually owns each part of a self-managed Keycloak rollout and which skills each part needs, so you can see where a partner adds the most value.
| Work part | Usual owner | Skills needed |
|---|---|---|
| Identity requirements and policy decisions | In-house (identity and security leads) | Knowledge of your user populations, sign-in policy, MFA rules, token lifetimes and audit obligations |
| Application client registration | Shared (application teams with identity team review) | Understanding of OIDC and SAML flows, redirect URI rules, scopes and role or group mapping for each application |
| Database and infrastructure provisioning | Platform team | Managing a supported database such as PostgreSQL, network segmentation, TLS certificates, DNS and load balancers in your environment |
| Keycloak deployment design and build | Often outsourced when the team lacks recent Keycloak experience | Keycloak clustering and high availability design, reverse proxy configuration, realm structure, and production configuration |
| Kubernetes and Operator setup | Platform team, with a partner where the Operator is new to the team | Kubernetes operations, Operator Lifecycle Manager, custom resource management and manual update approval practices |
| Independent security verification | Independent third party, scheduled by the security team | Application and infrastructure security testing, review of admin console exposure, token handling and brute force settings |
| Custom themes and SPI work | Outsourced or a dedicated developer, depending on skills | Java development against Keycloak SPIs, theme templating, and retesting each change against new Keycloak releases |
| Day-to-day operations after go-live | In-house operations, with an optional support retainer | Upgrade testing, database maintenance, monitoring and alert response, and reading release upgrade notes |
What goes wrong and how to prevent it
Most Keycloak rollout problems come from decisions made late or changes applied without review. Each card names a failure pattern and the check that prevents it.
Realm structure set too early
Realms define user stores, clients, roles and login policy, so a layout chosen before identity owners agree on users and roles is costly to reverse. Map which user populations exist, which applications share them, and which roles each owner approves. Confirm these decisions in written workshops before any realm is created.
Database and HA left undecided
Keycloak supports several production databases, and both supported high availability designs need a synchronously replicated database. Leaving the database choice open until late, or running a development file database, leaves the cluster without shared state. Confirm the engine version against the database guide, the replication mode and failover behavior with your database team before installation.
Unplanned automatic upgrades
Keycloak migrates its database schema at startup by default, and an operator can apply updates automatically unless manual approval is set. Either change can alter production data outside a change window. Plan manual schema migration for large deployments, set operator updates to manual approval, and rehearse each upgrade on a copy of the database.
26.8 changes to mail and logout
The 26.8 upgrade notes enforce StartTLS for SMTP with no plaintext fallback and require signature validation of backchannel logout tokens from external providers. Password reset and alert mail can fail without an obvious error, and logout requests from partner systems can be rejected. Test delivery through your relay and verify logout tokens from each external provider in staging before upgrading.
Admin console on public hostnames
The admin console and Administration REST API should sit on a different hostname or context path from public frontend URLs. If they share a host or path, administrative endpoints can be reached from the internet. Confirm that reverse proxy path rules block admin paths on public listeners, then test those rules from outside your network.
Cutover without a rollback path
A go-live that moves applications to the new realm without a tested reverse path leaves no safe way back if sign-in fails. Keep the previous identity source reachable, record every client and redirect URI change, and name the person who decides on rollback. Rehearse the switch and the reversal on a staging copy of the realm before the production window.
How the work changes by starting point
On virtual machines, the work centers on infrastructure you own. The team builds the node layout, service configuration, database connection and reverse proxy by hand, so most of the plan covers hosts, runbooks and change control.
- Scope: VM count and sizing, load balancer, reverse proxy, and a supported production database such as PostgreSQL 14 to 18
- Skills: Linux administration, TLS certificate handling, database administration and configuration management
- Sequencing: Provision the database and network paths first, validate TLS and hostnames on one node, then add the remaining nodes
- Watch for: Configuration drift between nodes, manual changes that nobody records, and service restarts that are not coordinated with the load balancer
With the Keycloak Operator, the work shifts toward Kubernetes platform operations. The Operator manages Keycloak, realm import and client custom resources, so realms and clients can be defined as code and reviewed like other cluster changes.
- Scope: Cluster capacity, ingress, database connectivity, secret handling, and whether realms and clients are stored in Git
- Skills: Kubernetes operations, Operator Lifecycle Manager or kubectl installation, GitOps workflow and custom resource authoring
- Sequencing: Confirm the cluster platform and install method, set operator updates to manual approval, then deploy Keycloak and import realms
- Watch for: Automatic operator updates that change versions without a change window, and realm import files that drift from the live configuration
When the network is restricted, connectivity assumptions change the whole plan. Container images, packages, certificates and mail relays must be mirrored or reachable from inside the boundary, and every update path has to work without internet access.
- Scope: Artifact mirroring, an internal certificate authority, an internal SMTP relay, and a documented offline update procedure
- Skills: Registry and package mirroring, PKI operations, and network security controls
- Sequencing: Build and verify the artifact bundle on an isolated staging network before the production install, then confirm which features need outbound access
- Watch for: Social login and external brokering that assume internet access, and SMTP relays that must support StartTLS, which the 26.8 upgrade notes require without plaintext fallback
When Active Directory must stay authoritative, directory integration becomes the central design question. Read-only federation with careful attribute and group mapping usually fits this case, and the directory team needs a voice in every decision about roles.
- Scope: LDAP or Active Directory federation mode, attribute and group mappers, bind account credentials, and Kerberos if integrated desktop sign-in is required
- Skills: Active Directory administration, LDAP schema knowledge and identity design
- Sequencing: Agree the authoritative attributes and group model with the directory owners, then test federation in a non-production realm before enabling synchronization
- Watch for: Writable federation that changes directory objects, and group mappers that grant roles through nested groups in ways application owners did not expect
The choice between the community project and the Red Hat build of Keycloak affects procurement, support and the release line you run, more than the core build. The Red Hat build is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On.
- Scope: Whether vendor support terms are required, which component versions are covered, and the written subscription quote
- Skills: Vendor support processes, change management and the same Keycloak administration skills
- Sequencing: Decide before the build starts, because image sources, support paths and version lines shape the runbook
- Watch for: Assuming subscription terms or support scope without a written quote, and version lines that differ from community releases, so confirm the current product version with Red Hat
What the client needs to provide
Before design starts, the client must name owners and make several decisions, because each missing input adds discovery time and change requests to a fixed-scope plan. Name one accountable owner each for identity, the applications that will sign in through Keycloak, and the infrastructure that will host it. The identity owner decides realm structure and login policy, the application owners confirm their protocol and redirect settings, and the infrastructure owner provides network paths and certificates. Without named people, design decisions wait on email threads and the schedule slips.
Provide access to the environments Keycloak will run in: cloud accounts, data centers or air-gapped networks, plus the firewall and load balancer change process. Decide the hosting model and the database platform from the supported list, since Keycloak supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The database choice drives the high availability design, because both supported multi-site designs need a synchronously replicated database. Confirm whether your team already runs that database platform and who supports it.
Supply the application inventory: for each application, the protocol (OpenID Connect, OAuth 2.0 or SAML 2.0), the redirect URIs, logout URLs, token and session needs, and the roles or groups it expects. Each application becomes a client to configure and test, so the count drives effort more than any other single factor. Add the directory and identity source details, including LDAP or Active Directory connection data, service accounts, group structure and whether any identity provider will be brokered. Read-only federation and writable federation take different amounts of design work.
Provide your certificate and DNS plans. Keycloak production guidance calls for TLS on all communication, and the admin console and Administration REST API need a different hostname or context path from public frontend URLs. Confirm who issues certificates, the expected lifetime and renewal process, and the internal or public DNS names. SMTP details are also required: host, port, authentication, sender address and a test mailbox. Keycloak 26.8 enforces StartTLS without plaintext fallback, so confirm your mail relay supports it before go-live.
Finally, name a decision-maker who signs the written scope. That person approves the number of realms, environments, high availability target and support model, and their signature fixes what the quote covers. Changes after signature are priced as change requests, so ask the sponsor to confirm the scope items above before the statement of work is issued.
Frequently asked questions
Does Keycloak itself carry a license fee for production use?
No license fee applies to the open source Keycloak project itself, which is licensed under Apache 2.0. Your costs sit elsewhere: the servers or cloud capacity that run it, a production-grade database, monitoring, backups, and the staff time to build and operate it. The Red Hat build of Keycloak is a separate, supported distribution based on the open source project, so choosing it is a distinct decision with its own subscription cost. Confirm the license terms of any theme, extension or other component you add, since those come from their own authors.
What drives Keycloak implementation cost and how is the quote set?
The main drivers are the number of applications to connect, the number of realms, whether you federate an existing LDAP or Active Directory, the high availability design across zones or sites, how many environments you need, and how much customization such as themes or custom authenticators you require. Recurring costs include infrastructure, database operations, monitoring, and upgrades, since the Keycloak project plans four minor releases a year. A DeployOpen quote follows the written scope, so ask for each driver as a separate line with its deliverables, assumptions and the work your team provides.
How long does a Keycloak rollout take for our organization?
No duration is stated here because it depends on the scope agreed with you: how many applications and realms move, which directory and brokering sources connect, the high availability design, and how many environments must be built and tested. Ask for a timeline in the written scope that lists phases, dependencies on your teams and approval points. When you compare timelines, check which assumptions each one depends on, such as application owners being available for testing and change windows being granted on schedule.
Can our own team implement Keycloak without an outside partner?
Often yes, if your engineers are comfortable with OpenID Connect, SAML 2.0, a relational database, and container or virtual machine operations, and they have time to test realms before production. Budget internal time for architecture decisions, client registration with each application owner, directory integration, load and failover testing, runbooks and on-call handover. The greatest risk usually sits in the first upgrade and in proving that failover works, so ask whether your team has done both. A partner can take on specific phases, and the written scope shows which work stays with you.
Which database and Keycloak release should we choose?
For production, choose a supported database from the Keycloak list, such as PostgreSQL 14 to 18, Microsoft SQL Server or Oracle Database, and favor the one your operations team already runs well. The current release is 26.8.1, published October 13, 2026, but confirm the version when the build starts because minor releases arrive several times a year. For high availability, the database must be synchronously replicated. The default dev-file database is for development only and should never carry production identities.
Does DeployOpen issue compliance certification for Keycloak deployments?
No. DeployOpen does not issue audit reports, attestations or certifications. We prepare the systems, access controls and evidence that an independent auditor or certification body reviews, such as documented sign-in policies, MFA settings, token lifetimes, admin access separation and audit event records. Ask your assessor early which evidence they need, and agree that evidence list in the written scope so it is collected as the build proceeds.
How DeployOpen scopes, delivers and hands over
DeployOpen plans, implements, hardens, documents and supports self-hosted Keycloak inside your own cloud accounts, data centers or air-gapped networks, with the rollout cost and phases agreed in writing before work starts. Engagements are fixed-scope, and the written scope sets the deliverables and timeline.
How we scope
- The written scope lists realms, applications, directory sources and sign-in methods covered by the rollout
- Application and client count is the first input we confirm, since it drives configuration and testing effort
- Environment plan (dev, test, staging, production) and the database engine are fixed in scope before any build
How we build
- Deploy Keycloak with TLS on all traffic, a reverse proxy with path restrictions and a separate admin hostname
- Configure the chosen high availability design and confirm the database is synchronously replicated as required
- Test realms, clients, federation and login flows in lower environments before any production cutover
How we hand over
- Deliver written runbooks covering install, configuration, backup, database schema migration and operator update approval
- Document realm, client and federation configuration so your team can review and change it later
- Walk your identity and platform team through operations, monitoring with metrics and failover tests before sign-off
How we support
- Ongoing support, upgrades and continuous testing are available under a retainer agreed in writing
- Upgrade planning covers reading release and upgrade notes for behavior changes before each minor release
- Ask your quote to separate one-time build work from recurring support so budgets can be compared
