Clerk or Keycloak for your app login: when each fits
Clerk fits teams that want prebuilt login screens and a hosted service, while Keycloak fits teams that must run identity inside their own infrastructure and have people to operate it. If your renewal or a change in per-user or per-connection pricing has prompted this review, start by asking whether the cost problem is the user count, the enterprise connections or both. Clerk removes most of the frontend work for sign-up, sign-in, profile and organization screens, so a small product team can ship login quickly. Keycloak instead gives you a server that handles OpenID Connect, OAuth 2.0 and SAML 2.0, and you build or customize the screens yourself through its theming system. Keycloak is licensed under the Apache License 2.0 and is a CNCF incubating project, so the software itself carries no license fee, but the work of running it does not disappear.
The decision turns on four questions you can answer before any proof of concept. First, how much frontend effort your team can absorb to build login and account flows that Clerk's components would otherwise provide. Second, how many enterprise customers need SAML or OIDC brokering into your app, because Keycloak handles brokering without a per-connection fee but each connection still needs configuration and testing. Third, where customer identity data must physically live. A self-hosted Keycloak puts that answer in your hands, which matters when residency rules apply. Fourth, who will operate a Java service that needs database backups, upgrades and high availability planning. Keycloak documents that both supported high availability designs need a synchronously replicated database, so name an owner for that layer before you commit.
Which option fits which scenario
This table matches common buyer situations to the option that usually fits better, with the condition that changes the answer. Read each row as a starting point: the right choice depends on who will run the identity system, where data must live, and how customer SSO is sold. Clerk tends to win when a small web team wants login shipped fast, while Keycloak tends to win when identity is treated as shared infrastructure that the organization operates itself.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Small web team with no identity staff | Clerk | Prebuilt components and hosted operations remove most login work. Keycloak fits only if someone on the team can own upgrades, database care and clustering. |
| B2B SaaS brokering customer identity providers | Keycloak | Keycloak can broker SAML and OIDC identity providers for each customer without per-connection fees. Confirm the connection management workflow your customer success team needs. |
| Regulated data residency in your own region | Keycloak | Keycloak runs in your own cloud account or data center, so customer identity data stays where you place it. Clerk does not offer regional residency, so confirm the requirement with its documentation. |
| Very large user base | Keycloak, after sizing | Self-hosted cost depends on your infrastructure and staffing, not per retained user. Size the cluster and database, and request a Clerk quote at your projected volume before deciding. |
| Existing Red Hat or Java operations | Keycloak | Teams already running JVM services, Kubernetes operators and Red Hat support can reuse those skills. Red Hat build of Keycloak adds vendor support if the organization needs it. |
| Multi-tenant customer identity with per-customer branding | Clerk or Keycloak, depending on staffing | Clerk offers organizations with a faster start. Keycloak handles realms and theming well but needs more design and operations work for each tenant model. |
| Frontend components and fast app integration | Clerk | Clerk's prebuilt UI and SDKs shorten the path to working login screens. With Keycloak, plan to build or theme your own login and account pages. |
What your team builds with Clerk and what it builds with Keycloak
Clerk ships prebuilt components and a hosted account layer, so most login UI work is already done. Keycloak ships a full identity server with a generic admin console, so your team designs and hosts the screens, tenant model and automation that Clerk otherwise supplies. The cards below separate those two shapes of work.
Prebuilt sign-in components and screens
Clerk provides drop-in React and other frontend components for sign-in, sign-up, profile and organization switching, so a typical app team wires them in rather than building forms. With Keycloak, the login, registration, password reset and account pages come from its built-in themes, and your team decides which of them to override, which frontend libraries call the OpenID Connect endpoints, and how they behave on mobile. Confirm current component coverage, including passkey and MFA screens, in Clerk's documentation and in Keycloak's account console documentation before you size the frontend work.
Theming and login page customization
Clerk customizes appearance through its component API, so branding changes stay inside the hosted components. Keycloak uses FreeMarker templates and theme properties that you package, version and deploy to every node, so brand changes become a build and release task. Plan for template upgrades after each Keycloak release, since the upgrade path has to be tested against your custom pages. Ask whether your designers will work in code or need a separate theming workflow.
Organizations and tenant structure
Clerk's organizations model covers membership, roles and invitations for B2B apps, which the application reads through its SDK. In Keycloak, you map tenants onto realms, groups, roles or client scopes, and each choice changes how users, clients and branding are isolated. Realm-per-tenant gives strong separation but multiplies administration, while groups and roles keep one realm but need careful claim design. Write down the tenant model before building, because changing it later affects tokens, exports and every application.
Admin console and API automation
Clerk's dashboard and Backend API let engineers manage users, organizations and sessions from code with a hosted service behind them. Keycloak exposes an Admin REST API and a web admin console, and your team owns the scripts, service accounts, and the Keycloak Operator resources such as KeycloakRealmImport and KeycloakOIDCClient if you run it on Kubernetes. Decide early which configuration lives in code and which is changed by hand, and confirm the Admin API endpoints for your target version in the Keycloak documentation.
Capability by capability: Clerk and Keycloak
This table sets Keycloak's documented capabilities against the categories a Clerk buyer typically evaluates. Where Clerk's exact behavior is not covered by our sources, the cell tells you what to confirm with Clerk before deciding. Use it as a checklist for your own requirements, not as a verdict on either product.
| Capability | Keycloak (self-hosted) | Clerk (hosted) |
|---|---|---|
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 are supported natively | Confirm with Clerk which protocols its hosted SSO and API layers expose to your application and to customer identity providers |
| User federation | Built-in federation with existing LDAP and Active Directory servers | Confirm whether Clerk can federate with your existing directory or only imports and syncs users |
| Identity brokering | Brokers customer identity providers so your app keeps one login flow | Confirm the per-connection terms and which enterprise providers Clerk supports today |
| Admin console | Web admin console for realms, clients, users and roles | Hosted Clerk dashboard; confirm which admin actions require a paid seat or plan |
| Fine-grained authorization | Authorization services for policies and permissions on resources | Confirm how Clerk's organization roles and permissions map to your own resource model |
| License | Apache License 2.0, with source code available for inspection and modification | Proprietary hosted service; review Clerk's terms for export and exit rights |
| Foundation status | Cloud Native Computing Foundation incubating project | Commercial vendor product; not a foundation project |
| Production databases | MariaDB, Microsoft SQL Server, MySQL, Oracle, PostgreSQL 14 to 18, Aurora PostgreSQL, Azure SQL and others | Managed by Clerk; you do not choose the database |
| High availability | Documented single-cluster and multi-cluster designs, both needing a synchronously replicated database | Availability and SLA terms come from Clerk; ask for the current service commitments in writing |
| Upgrade cadence | Four minor releases a year and a major release every two to three years; breaking changes in minor releases are opt-in | Clerk ships changes to its hosted service; confirm how API version changes are announced and pinned |
How Keycloak brokers Entra ID and customer SAML logins
Your application trusts Keycloak as its single OIDC or SAML provider, and Keycloak in turn trusts each upstream identity provider, such as Microsoft Entra ID or a customer's SAML IdP, through a separate identity provider entry in the realm. When a user signs in through Entra ID, Keycloak receives that user's assertion, validates it against the configured trust, and then issues its own token to your application. Your app never needs a direct trust relationship with the customer's IdP. On first login, Keycloak can create a local user record or link the external identity to an existing one, and the first broker login flow decides which of those happens. Review that flow before go-live, especially whether linking by email is allowed, because it determines whether one customer's account can be claimed by another identity.
On Clerk, enterprise connections are often priced per SAML or OIDC connection under the reader's contract, so the cost is only a per-connection fee if that is what their agreement says. Confirm the exact terms with Clerk before modeling. In Keycloak, the connection count is not a license meter. The practical limits are how many identity providers your team configures, tests and monitors, how each mapper and claim is maintained, and how certificates and metadata are rotated. Plan an owner for each connection, a metadata refresh process and a test login for every customer tenant. Ask any implementation partner to price these operating tasks in the written scope, since they recur as customers are added.
LDAP and Active Directory federation is a separate case from customer brokering. Here Keycloak connects to an employee directory through user federation, so staff can sign in with their directory credentials while Keycloak keeps a local record for each user. Decide which side owns passwords, which attributes are imported, and whether group membership maps to application roles. Federation is usually read-only for the directory, so confirm with your directory team how account disablement and password changes will flow through. Use a test realm with a restricted service account before connecting production directories, and document the sync schedule so that an offboarded employee cannot keep an active session across both systems.
Who holds the identity data and who can run the service
Moving from Clerk to Keycloak changes where customer identity records and password hashes live, and who is responsible for keeping the service running. The five decisions below connect data custody, operating duties, licensing and compliance evidence, so each can be settled before a migration plan is written.
Where identity records and hashes live
Under Clerk, user records, sessions and password hashes sit in Clerk's hosted service, and Clerk does not offer regional data residency. With Keycloak, realms, users and credentials sit in a database inside your own cloud account or data center. Confirm which database engine you will use from Keycloak's supported list, where backups are stored, and who in your organization can read the database tables directly. Ask your Clerk contact for the exact export format before you plan the cutover.
Backups, patching and upgrades
A self-hosted Keycloak cluster makes your team responsible for backups, restore tests, security patches and version upgrades that Clerk performs for you. Keycloak ships four minor releases a year under its stated plan, and the operator documentation strongly recommends manual approval mode for operator updates. Decide who owns each upgrade window, and test restores of the realm data before go-live, since a realm export is documented as having limits as a backup mechanism.
High availability and the database
Keycloak's supported high availability designs need a synchronously replicated database, so availability depends on how your database is built as much as on Keycloak itself. Clerk's uptime is its own responsibility under its terms, while your uptime under Keycloak depends on your cluster design, zone spread and failover testing. Ask your platform team who will operate the database, what recovery targets the business expects, and whether an existing managed PostgreSQL service meets the replication requirement.
License terms and supported distributions
Keycloak is licensed under Apache 2.0, which allows you to run, modify and redistribute the software without a per-user license fee from the project. Clerk is a paid hosted service, so its fees are a recurring commercial relationship with a single vendor. If you want a vendor to carry support and patching obligations, the Red Hat build of Keycloak is a supported distribution based on the open source project, and you should confirm its terms and current version with Red Hat before budgeting.
Compliance evidence and auditor roles
Under a self-hosted model, your team produces the evidence that auditors examine, including access reviews, change records, backup test results and configuration baselines for Keycloak. DeployOpen can help plan and prepare those controls and evidence, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination. Before choosing Keycloak, ask your auditor which evidence they will expect from an identity system you operate yourself and which parts Clerk's own assurance reports currently cover.
What each option costs to run, by component
Clerk bills as a subscription, and the invoice is built from several components that scale differently. The base plan covers the service tier you select. Retained users are billed on top of that, so the more people who sign in during the billing period, the larger the overage line. Enterprise SSO connections are a separate charge, so a B2B product that adds SAML or OIDC customers pays for each connection they set up. Dashboard seats add cost when more staff need access to the Clerk dashboard. Read each line on a recent invoice and map it to these four components.
- Plan fee: the recurring base charge for the tier your application uses.
- Retained users: usage charges that rise with the number of users retained in the billing period.
- Enterprise connections: per-connection charges for SSO setups that customers request.
- Dashboard seats: charges for additional team members with dashboard access.
- Add-ons: any optional features on your plan, such as directory sync, which Clerk prices separately.
Check current prices on Clerk's pricing page before modeling, because tiers and rates change. Ask your account contact to confirm how retained users are counted and whether connection fees apply to test environments.
Keycloak has no license fee because it is licensed under Apache 2.0, so your costs come from the servers and cloud resources that run it. These are recurring and depend on how many nodes you run, how much memory each node needs for sessions and caching, and whether you run in one availability zone or several. Load from logins, token issuance and admin activity drives the size of each node. Most of the infrastructure cost is a monthly bill from your cloud provider or data center, and it grows as your user count and traffic grow.
- Compute nodes: the number of Keycloak instances you run, sized for peak login traffic.
- Load balancing and networking: ingress, certificates and traffic between zones.
- Non-production environments: staging and test realms that mirror production.
- Monitoring: metrics and log storage for the Keycloak metrics endpoint and your existing stack.
- Backups: storage for database snapshots and exported configuration.
Ask your platform team to size nodes against a load test with your expected peak logins, because the right size depends on your traffic pattern rather than on user count alone.
Keycloak stores realms, users and sessions in an external relational database. PostgreSQL is a common choice, and the supported versions include PostgreSQL 14 to 18. The high availability design adds cost because both supported multi-node designs need a synchronously replicated database. That means a primary and at least one standby, plus the licensing or hosting cost if you choose a managed service. These costs are recurring, and they rise with the size of the database, the number of replicas, and the storage needed for session and audit data.
- Managed or self-run database: cloud database service fees or the hardware and admin time for a self-run cluster.
- Replication: standby instances that stay in sync across zones.
- Storage and retention: growth from users, sessions and event logs.
- Multi-cluster design: the v2 multi-cluster approach needs its own infrastructure per site.
- Backup and restore testing: recurring storage plus time to test restores.
Confirm which database service and replica count your design requires, and whether your cloud provider's managed offering meets your data residency terms.
The largest recurring cost for many teams is staff time. Someone must own the Keycloak configuration, run upgrades, patch the operating system and database, and respond to incidents. Upgrade frequency matters. Since Keycloak 26.0 the project plans four minor releases a year, and breaking changes in minor releases are opt-in, which lowers the risk of each upgrade but keeps the work recurring. The Operator documentation recommends manual approval for updates, which adds a human review step to each release.
- Platform engineering time: deployment, configuration and on-call for the identity service.
- Upgrade cycles: testing and rolling out four minor releases a year, plus major upgrades every two to three years.
- Schema migration: automatic at startup by default, or applied manually for large deployments.
- Security reviews: patching and periodic configuration reviews.
- Operator management: time spent approving and tracking operator updates on Kubernetes.
Ask your team to estimate hours per release cycle, and ask whether automated testing exists for realm configuration before you commit to an upgrade cadence.
Keycloak is free to use, but production support is a separate decision. Options include an in-house team, a commercial distribution with vendor support such as the Red Hat build of Keycloak, or an implementation partner on a fixed-scope or retainer basis. Migration from Clerk is a one-time cost covering export, configuration of realms and clients, and cutover. Ongoing retainers cover upgrades, monitoring and testing. DeployOpen plans and implements these engagements under a written scope, and quotes follow from that scope.
- One-time migration: exporting users, configuring clients and brokers, rebuilding login screens, and testing.
- Vendor support: subscription fees for a supported distribution, if you choose one.
- Retainer or managed service: recurring fees for upgrades, monitoring and incident response.
- Training: time for your team to learn the admin console, realms and the Operator.
- Parallel running: the period when Clerk and Keycloak run side by side, which adds cost until cutover.
Ask any provider for a written scope listing deliverables, responsibilities and what happens after handover, so you can compare quotes on the same basis.
Running Keycloak at high user counts and the Java operations it brings
At high user counts the first decision is the database, not the Keycloak nodes. Keycloak supports PostgreSQL 14 to 18, Amazon Aurora PostgreSQL, Azure SQL, MySQL, MariaDB, Microsoft SQL Server and Oracle Database in production, and the development file database must never reach production. Size the database for session and event volume, not only for the stored user count, and confirm the sizing with a load test that mirrors your login peaks. Both supported high availability designs need a synchronously replicated database, so ask your database team how replication and failover will be run before you pick a design. Keycloak documents three architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) that do not need an external Infinispan cluster, and the multi-cluster v1 design, which is deprecated and should not be chosen for a new build. Read the Keycloak high availability overview before choosing between the first two.
If you run on Kubernetes, the Keycloak Operator is the recommended installation path, installed through Operator Lifecycle Manager. The Operator manages the Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources, so client configuration can live in version control. The Operator documentation strongly recommends manual approval mode for operator updates, which stops a new release from upgrading production without a change record. Keycloak also migrates its database schema automatically at startup by default. For large deployments the upgrading guide suggests manual migration instead, where your DBA reviews and applies the SQL before the new nodes start. Decide which mode you will use and write it into the runbook, because it determines how long a rolling upgrade takes and who must be available for it.
The operating work is mostly Java. Keycloak runs on the JVM, so your team owns heap sizing, garbage collection behavior, container memory limits, thread pools and the metrics that show them, which Keycloak exposes through its metrics configuration. Plan these as recurring work, not a one-time install. Release cadence matters here too: since Keycloak 26.0 the project plans four minor releases a year and a major release every two to three years, and breaking changes in a minor release are opt-in. The current release, 26.8.1, was published on October 13, 2026. Budget regular upgrade windows, test each minor release in a staging realm with production-like data, and confirm with your own vendor or partner who will carry the upgrade effort if you buy support.
What a move from Clerk to Keycloak involves
The sequence turns Clerk's hosted login into a Keycloak realm you run, with users, clients, customer identity providers and a tested cutover plan in place before any production traffic moves.
Inventory the Clerk features in use
List every Clerk feature your application depends on: prebuilt components such as sign-in and user profile, organizations and roles, enterprise SAML or OIDC connections, session and token settings, user metadata, webhooks and any custom sign-up fields. Name the owner of each item and note which application code calls Clerk's SDK or API. This inventory defines the scope of the migration and is done when every feature has a row showing where it is used and what replaces it in Keycloak. Keycloak's own documentation covers realms, clients, identity brokering and user federation, so map each Clerk feature to one of these concepts before moving on.
Export users and verify the export
Export users from Clerk using the dashboard or its API, and pull organizations, memberships and metadata separately, since a user export may not carry all of them. Ask Clerk in writing whether the export includes password hashes, which algorithm they use and how they are formatted, because this determines whether users can keep their passwords after the move. Load the export into a spreadsheet or script and check record counts, email uniqueness, verified-email flags and metadata fields against Clerk's dashboard totals. The step is complete when you have a verified file with a documented list of what is missing and what needs a password reset.
Stand up Keycloak on a supported database
Deploy Keycloak in a staging environment inside your own infrastructure, using a production database from Keycloak's supported list, such as PostgreSQL in a supported version range. Do not use the development file database for anything beyond testing. Decide whether you will use the Keycloak Operator on Kubernetes or a plain deployment, and set the operator update mode to manual approval, as the operator documentation recommends. Confirm your high availability design and its synchronous database replication before production. The step is done when a staging instance starts cleanly, passes a health check and shows its metrics endpoint working.
Rebuild login screens and theme
Clerk's prebuilt components do not carry over. Decide which screens you keep as Keycloak's hosted login pages and which you rebuild, then apply a custom theme for logos, colors, text and any required fields, including sign-up, password reset, MFA enrollment and account pages. Review each screen against the flows your users follow in the current Clerk-based application, including error states and localized text. Keep the theme in version control so changes are reviewed and reproducible. The step is complete when a tester can finish every user journey in staging, from registration to profile changes, without seeing an unbranded or broken page.
Configure clients and brokered identity providers
Create a Keycloak client for each application and API, with redirect URIs, allowed scopes and token lifetimes that match your current setup. Replace the Clerk SDK calls in your application with OpenID Connect integration, and map Clerk organizations to Keycloak groups, roles or organization-aware claims in your token design. For each enterprise customer connection, configure an identity provider in Keycloak using the SAML or OIDC settings from that customer, then test a login from each connection in staging. Compare the claims your application receives against what it received from Clerk. The step is done when every client and customer identity provider passes an end-to-end login test with the expected user attributes.
Test user import and password handling
Import a copy of the verified user set into the staging realm using the Keycloak admin tools or a script against the admin API. If you received password hashes from Clerk, check that a test user can sign in with the original password. If you did not, or the hash format is not supported by Keycloak, plan a password reset flow and an email communication to affected users. Confirm this approach with Clerk and test it in staging before any production change, since Clerk's export behavior is the deciding factor. The step is done when you have a written decision for each user group and a successful test login for each group.
Plan the cutover and rollback
Agree on a cutover sequence with the people who own the application, support and customer success teams. Define the order in which you switch the application's login from Clerk to Keycloak, how you will handle active sessions, whether users sign in again after the switch, and how you will communicate with enterprise customers whose connections change. Prepare a rollback path that keeps Clerk available until the new login is confirmed, and set a final export of any changes made during the transition. The step is complete when the cutover plan is signed off in writing, and a rehearsal in staging has produced the expected results for sign-in, sign-out, password reset and rollback.
Questions teams ask before switching from Clerk to Keycloak
How much does moving from Clerk to self-hosted Keycloak cost?
The cost depends on the work the move needs, not on a list price, because Keycloak is Apache 2.0 licensed and carries no license fee. The one-time spend covers planning, the user export and import, rebuilding login screens and theming, configuring customer identity providers, testing, and cutover. The recurring spend covers the infrastructure for Keycloak and its database, the staff who run it, and any support contract you choose. Ask any quote to split these lines and to state which Clerk features are in scope, such as organizations, enterprise connections and dashboard roles. DeployOpen does not publish prices, so a quote follows from a written scope.
How long does a Clerk to Keycloak migration take?
The timeline is set by the number of applications, the number of enterprise connections, how much of the Clerk user interface you rebuild, and how many users must move without a forced password reset. Plan for a parallel run in which both systems serve logins while you test, then a controlled cutover. Ask for milestones in the written scope with named deliverables for each application, and confirm how the team will verify that sessions, tokens and redirect URIs work before switching. Any duration you are given should be tied to that scope.
What work does our team have to supply during the move?
Your team supplies knowledge and access that only you hold: the list of applications and their redirect URIs, the Clerk configuration and organization model, the identity providers your customers use, the attributes your apps read from user profiles, and sign-off on the login flows. Your team also needs an owner for the Keycloak environment after launch, including who approves operator upgrades and who responds to alerts. Ask the implementation partner to list these inputs in the scope so that delays are visible early.
Can we move Clerk to Keycloak without an outside implementation partner?
Yes, a capable internal team can do it, provided it has experience with OpenID Connect, SAML, Kubernetes or a comparable container platform, and a PostgreSQL or other supported database. Keycloak's documentation covers realm export and import, database configuration, high availability and the Operator, but it does not map Clerk's components or organization model for you. Before deciding, check whether your team can own the security review, the load testing and the upgrade routine. Outside help is most useful for the parts you have not done before, and it can be scoped to those parts only.
Can Keycloak import users with their existing password hashes from Clerk?
Whether password hashes can move depends on what Clerk exports and in what format, and on whether Keycloak can verify that hash scheme, so confirm both before planning the cutover. Keycloak supports importing users and credentials through its realm import and its user APIs, but the hash algorithm and parameters must match what Keycloak accepts. If hashes cannot be carried over, plan a password reset flow or a staged migration that upgrades passwords at the next successful login. Ask the vendor for the export format and check the result on a test realm before committing to a date.
How are Keycloak upgrades handled after the move?
Keycloak plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release will be opt-in. Schema migration runs automatically at startup by default, but large deployments can apply the SQL manually, which the upgrading guide suggests. The Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended upgrades. Ask for a written upgrade runbook covering staging tests, database backups before each change, rollback steps and the schedule for reviewing release notes.
Does Keycloak cover Clerk organizations and per-customer single sign-on?
Keycloak covers the core needs: it brokers SAML 2.0 and OpenID Connect identity providers, supports identity brokering, and provides an admin console and fine-grained authorization. Clerk's organization features, such as organization membership and roles inside your application, do not map one to one onto Keycloak realms, groups and roles, so the data model needs design work. Ask for a written mapping of each Clerk organization feature to a Keycloak construct, including how per-customer identity provider settings are isolated and administered, and confirm which parts your own application must implement.
What does running Keycloak in production require from our operations team?
Operations work includes running Keycloak on a supported database, such as PostgreSQL 14 to 18 as listed in the database guide, configuring a high availability design that uses a synchronously replicated database, monitoring through the metrics endpoints, and maintaining backups. Keycloak's export and import commands are documented as having limits as a backup method and require all nodes to be stopped during the process, so plan database-level backups instead. Ask for the monitoring, backup and restore tests to be part of the written scope.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Clerk vs Keycloak, we start by agreeing on which application logins, customer SSO connections and user sources must move, then build and document a Keycloak deployment you run yourself.
How we scope
- We map your Clerk applications, organizations and enterprise SSO connections to the Keycloak realms, clients and identity brokers they need.
- We confirm which user sources, such as an existing LDAP or Active Directory server, Keycloak must federate during the evaluation.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Keycloak in your environment, choosing a supported production database and a high availability design that matches your uptime needs.
- We configure theming and login flows to replace Clerk's prebuilt components, and test OIDC and SAML logins against your applications.
- We set up backups, upgrade procedures and metrics, and document how realm exports are handled given the stop-all-nodes limitation.
How we hand over
- You receive architecture diagrams, configuration records, runbooks and test evidence covering each login path and customer SSO connection.
- We walk your platform and security teams through daily operations, including how the Keycloak Operator and manual approval mode for updates are used.
- We prepare the controls and evidence that compliance assessments need, while independent auditors and certification bodies issue any attestation.
How we support
- Ongoing support, Keycloak upgrades and continuous security testing are available as retainers after handover.
- We can plan Keycloak minor and major release upgrades against the project's documented release cadence and opt-in breaking changes.
- Before any quote, we ask you to confirm your user counts, SSO connection volume and hosting constraints so the written scope is accurate.
