Keycloak vs Logto: which fits your SaaS login?
Choose Keycloak when your SaaS product needs a mature Apache-2.0 identity server that speaks SAML alongside OpenID Connect, can federate users from LDAP or Active Directory, and comes with a long-established admin console. It fits a team willing to run a clustered Java service and its relational database, with the operational ownership that implies. Choose Logto when you want a developer-oriented customer identity platform under MPL-2.0 with OAuth 2.1, SAML and organizations built in, and your team can accept the default of one administrator account in self-hosted OSS or moves to Logto Cloud, which includes team management. Both options deliver login for B2B tenants, so the choice is about operations and administration more than feature checklists.
The decision turns on four questions. First, who manages customer tenants: if your customers' administrators must set up their own users and identity providers, confirm how each platform delegates that work, since Logto's organizations support organization RBAC, member invitations and just-in-time provisioning, while Keycloak's model is built around realms and its Organizations feature. Second, which protocols your customers require: a SAML-only enterprise buyer should be checked against each product's current release notes rather than assumed. Third, how many people administer the platform, because the single-admin default in self-hosted Logto OSS may block a team before any technical issue appears. Fourth, who owns database operations and upgrades, since Keycloak requires a supported production database and a tested upgrade path, and Logto requires Node.js and PostgreSQL 14 or later. Write these answers down before you request quotes.
Which platform fits which SaaS login scenario
This table maps common SaaS login scenarios to the platform that fits each one better, with the condition that decides it. Read each row as a starting point: the named platform wins under the stated condition, and the 'what changes the answer' column shows which facts would flip the choice.
| Scenario | Better fit | Why and what would change the answer |
|---|---|---|
| B2B SaaS where customers bring their own SAML identity providers | Keycloak | Keycloak supports SAML 2.0 and brokers logins to external SAML providers, and it can federate from LDAP or Active Directory. Logto also states SAML support, so confirm the per-organization SAML setup you need against the current Logto documentation before deciding. |
| Consumer app needing social and passwordless login | Logto | Logto is built as auth infrastructure for SaaS and AI apps, with a developer-oriented focus on sign-in experiences. Confirm the specific social connectors and passwordless methods you need in the current Logto release, since those lists change between versions. |
| Small product team with one administrator | Logto | Self-hosted Logto OSS supports only one administrator account by default, which suits a single operator. Adding more admin members needs a self-hosted license, so this changes if you need several people administering the service. |
| Team that needs several administrators on a self-hosted service | Keycloak | Keycloak's admin console is not limited to a single administrator account in the supplied facts. Confirm role delegation for your operators in the Keycloak server administration guide before you commit, because it is the deciding factor here. |
| Enterprise platform team running SSO for internal and customer apps | Keycloak | Keycloak covers OIDC, OAuth 2.0, SAML 2.0, identity brokering, LDAP and Active Directory federation, and fine-grained authorization in one server. Logto wins only if the internal estate is small and the customer-facing login is the main job. |
| Organizations with a strict Apache-2.0 license requirement | Keycloak | Keycloak is Apache-2.0 licensed, while Logto's repository is MPL-2.0. Both are open source, but teams with policies tied to a specific license should confirm how their legal team reads MPL-2.0 file-level obligations. |
| B2B tenants that manage their own users inside your product | Logto | Logto offers organizations with organization RBAC, member invitations and just-in-time provisioning, which map directly to customer tenants. Confirm how organization admins are delegated in the self-hosted build, since the single-admin limit applies to the server administrator account. |
| Team with limited capacity to run a stateful identity service | Logto | Logto OSS needs Node.js and PostgreSQL 14 or later, and its docs recommend Logto Cloud for official support. If you cannot run the service yourself, the managed Logto Cloud option changes the cost picture, so compare it with self-hosting before deciding. |
How Keycloak and self-hosted Logto are built and deployed
Both platforms are self-hosted and both put a relational database at the center of their operations. The difference lies in what each one asks your team to build, size and keep running after go-live, from database high availability to how upgrades reach production.
Keycloak database requirement
Keycloak needs a relational database in production. Its supported options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL, and Azure SQL, while the default dev-file database is for development only. The database choice sets your backup, patching and DBA skills, so confirm which engine your operations team already runs well before you commit.
Keycloak high availability designs
Keycloak documents three high availability architectures: one cluster optionally spread across availability zones, multi-cluster v2 without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs need a synchronously replicated database, which adds network latency and cost to every site you connect. Ask your database team whether synchronous replication is available in your environment before choosing a design.
Keycloak Operator and update approval
On Kubernetes and OpenShift, the Keycloak Operator manages Keycloak and its realm and client custom resources, and it installs through Operator Lifecycle Manager, which Keycloak recommends, or through kubectl. The documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Your change board should own each approved upgrade, not the cluster's default settings.
Logto OSS runtime requirements
Self-hosted Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0. The docs recommend at least 2 vCPU, 8 GiB of memory and 256 GiB of disk as a starting point. Your team will run a Node.js service and a PostgreSQL database, so check that you can patch and monitor both, and confirm the sizing against your own tenant and login volume.
Logto Docker Compose warning
Logto's documentation warns against using its Docker Compose file in production, because the bundled Postgres database is recreated on each run. The official image can run with a plain docker run command instead, with an external PostgreSQL database that your team backs up and restores. Treat the Compose file as a trial setup only, and plan the production database before the first deployment.
Sizing from tests, not defaults
Neither platform's documentation gives a sizing that fits your login volume, token lifetimes or federation load. Keycloak sizing must come from its documentation and your own load tests against a production-like database and cluster topology. Ask the vendor or your partner for the load profile behind any sizing they propose, and keep those tests as a repeatable part of each upgrade.
Keycloak and Logto feature by feature
This table compares Keycloak and Logto on the capabilities a SaaS team usually asks about first, from license and protocols to B2B organizations and self-hosted admin limits. Read each row against your own requirements, and confirm any detail marked for confirmation in the vendor documentation before you decide.
| Capability | Keycloak | Logto |
|---|---|---|
| License | Apache-2.0, a permissive license with no copyleft obligation on the server | MPL-2.0, a file-level copyleft license for the open source repository |
| OpenID Connect | Supported | Supported |
| OAuth 2.0 and OAuth 2.1 | OAuth 2.0 supported; confirm OAuth 2.1 profile behavior in the Keycloak server administration guide | Full OAuth 2.1 support stated in the Logto README |
| SAML | SAML 2.0 supported | Full SAML support stated in the Logto README |
| Identity brokering to external providers | Brokers logins to external OIDC and SAML identity providers | Enterprise SSO is listed; confirm which upstream connectors your self-hosted build includes |
| LDAP or Active Directory federation | Federates users from LDAP and Active Directory | Not listed in the supplied facts; confirm with Logto before assuming support |
| Organizations for B2B tenants | Realms plus Organizations feature; confirm the Organizations model in the Keycloak documentation | Organizations with multi-tenancy; confirm tenant isolation model in the Logto documentation |
| Organization RBAC and just-in-time provisioning | Confirm role and provisioning options against your B2B flow in the Keycloak documentation | Organization RBAC, member invitations and just-in-time provisioning listed in the Logto README |
| Production databases | PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle, Aurora PostgreSQL; dev-file database is not for production | PostgreSQL ^14.0 with Node.js ^22.14.0 for self-hosted OSS |
| Admin accounts in self-hosted OSS | Admin console with the admin accounts you configure | One administrator account by default; more admins need a self-hosted license |
| Latest release | 26.8.1, published October 13, 2026 | v1.45.0, published October 13, 2026 |
What the Apache-2.0 and MPL-2.0 licenses mean for each option
Keycloak is licensed under Apache-2.0, a permissive license that the project states in its LICENSE file. Apache-2.0 does not require you to publish changes you make to Keycloak, and it does not require a commercial subscription to run the server in production. The project is a Cloud Native Computing Foundation incubating project, which describes its governance and is separate from its license. If you want a vendor-supported build, Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On. Red Hat's product page showed version 26.6 as its latest, so confirm the current version before you plan around it.
- No copyleft obligation on the server: Apache-2.0 lets you modify Keycloak, embed it, or host it for customers without releasing your changes under the same license.
- Notice and attribution: Redistribution of Keycloak, including modified builds, carries Apache-2.0 notice and attribution duties that your legal team should track in your software bill of materials.
- Paid support is optional: Community releases come without vendor support contracts. Red Hat build of Keycloak adds a supported distribution and a Red Hat subscription, which is a separate purchase.
- Patent and trademark terms: Apache-2.0 includes a patent grant from contributors and does not grant rights to project trademarks, so check how you name any custom build.
Before you ship a modified Keycloak, ask counsel to confirm which notices, attributions and source offers apply to your distribution model.
Logto's repository is licensed under MPL-2.0, which is a file-level copyleft license. Under MPL-2.0, if you modify an existing Logto source file and distribute that modified file, the changed file stays under MPL-2.0 and its source must be made available to recipients. New files you add in separate modules can usually carry different terms, which is why counsel should review how your code is laid out. Self-hosted Logto OSS needs Node.js ^22.14.0 and PostgreSQL ^14.0. By default it supports only one administrator account, and adding more admin members requires a self-hosted license, so the license question also shapes operating roles.
- File-level copyleft: Changes to existing MPL-2.0 files that you distribute must remain under MPL-2.0, while separate files in your own modules may not be covered.
- Hosting is not distribution: Running a modified Logto internally or as a service you operate for your own customers may not trigger the same source obligations as shipping the software, so confirm this with counsel for your setup.
- Single admin by default: Self-hosted OSS supports one administrator account, and more admin members need a self-hosted license.
- Commercial license is separate: The admin-member limit is a product entitlement tied to a self-hosted license, not a change to the MPL-2.0 terms on the code.
Ask the vendor which edition and license you need for your planned number of administrators, and have counsel review your modification plan before you fork any file.
Logto Cloud is the vendor's fully managed service. You do not run the server, the database or its upgrades, and the vendor's docs recommend Logto Cloud for official support rather than self-hosting on third-party providers. Team management is included in Logto Cloud, which is the main difference from self-hosted OSS when you need more than one administrator. The license terms for the open source code still apply to what the project publishes, but your day-to-day obligations are governed by the service agreement, not by the MPL-2.0 file rules. Your customer data and tenant configuration sit with the vendor, so the contract, data location and exit terms matter as much as the license.
- Team management included: Cloud includes team management, so multiple administrators do not require a separate self-hosted license.
- Service terms govern operation: Uptime commitments, data processing terms, and exit or export rights come from the vendor contract, so request them in writing.
- Support path is defined: The vendor recommends Logto Cloud for official support, which differs from running self-hosted OSS on your own infrastructure.
- Less control over the server: You cannot modify the managed deployment the way you can modify a self-hosted fork, which affects custom code plans.
Before you choose Cloud, ask the vendor for the current terms, data residency options and the process for leaving the service with your data.
What drives the running cost of each platform
Running either platform costs more than the license line, which is free for both in their open source form. The cost sits in the database, the people who patch and upgrade the system, the support you buy or do not buy, and the edition you need for admin access or enterprise features. The cards below set out what each platform adds to that bill and what to ask for in a written quote.
Database and high availability
Keycloak needs a relational database in production, and its high availability designs require a synchronously replicated database in both supported architectures. Logto OSS requires PostgreSQL 14 or later and recommends at least 2 vCPU, 8 GiB of memory and 256 GiB of disk. Ask the quote to price the database service, its replicas, backups and the storage growth you expect for each platform, and confirm which of these your own cloud or data center already runs.
Deployment route and operator effort
Keycloak on Kubernetes is usually run through the Keycloak Operator, which is installed with Operator Lifecycle Manager or kubectl, while the Operator documentation strongly recommends manual approval for operator updates. Logto OSS is run from its official image with docker run, because its Docker Compose setup bundles a Postgres database that is recreated on each run and is not meant for production. Ask who maintains the cluster, the Operator and the database, and whether that work is in scope.
Upgrade cadence and breaking changes
Since Keycloak 26.0 the project plans four minor releases a year, and breaking changes in a minor release are opt-in, which lowers the risk of an unplanned change but still requires a test cycle on each release you adopt. Logto publishes frequent releases, including v1.45.0 on October 13, 2026, so upgrade testing is an ongoing cost. Ask the quote to state who tests each release, how many environments are covered and whether schema migrations run automatically or by hand.
Paid editions and admin seats
By default self-hosted Logto OSS supports only one administrator account, and adding more admin members needs a self-hosted license, while Logto Cloud includes team management. Keycloak's community release has no per-admin charge, but Red Hat build of Keycloak is a supported distribution sold by subscription when you need vendor support. Ask each vendor or partner in writing what an additional admin costs, which features sit behind a paid tier and what the subscription covers.
Support and managed hosting
Logto recommends Logto Cloud for official support rather than self-hosting on third-party providers, so a self-hosted Logto deployment carries more of the support burden. Keycloak support comes from the community or from a Red Hat subscription, and DeployOpen offers ongoing support and upgrades as retainers, scoped in writing. Compare the managed Logto Cloud fee against the internal staff hours and retainer scope you would otherwise need, and confirm response expectations before you sign.
Engineering skills and one-time work
Setup, SSO integration with your SaaS application, identity brokering and any migration from an existing identity store are one-time costs that scale with the number of applications and tenants. Keycloak adds Java and Kubernetes operating skills, while Logto adds Node.js and PostgreSQL skills. Recurring costs are hosting, patching, upgrade testing and on-call time. Ask the quote to split one-time work from recurring retainer work so you can compare the two platforms on the same basis.
Moving a SaaS login from one platform to the other
This sequence produces a tested path for moving a SaaS login between Keycloak and Logto without breaking existing tenants. It separates what carries over as standard OIDC or SAML configuration from what must be rebuilt and what depends on vendor-specific credential handling.
Inventory clients, tenants and identity providers
The current team lists every application client, each customer tenant or organization, every connected external OIDC or SAML identity provider, and every user source such as a directory or social login. Engineering and the identity owner complete the inventory together. It is done when each row names its protocol, redirect URIs, signing certificates, owning tenant and the number of active users, so nothing is discovered for the first time during cutover.
Map roles and organizations to the target model
Map each current realm, role, group and tenant membership to the target model. In Keycloak, that means realms, roles and groups, and in Logto, organizations, organization roles and application-level RBAC, which must be confirmed against the current Logto documentation. Product owners sign off on the mapping table. It is done when every existing permission has one target role, and any permission without an equivalent is recorded as an open decision.
Recreate clients and connectors on the target
Recreate each OIDC client and SAML service provider on the target platform, using the same redirect URIs, scopes, claim mappings and signing settings. Standards-based client configuration carries across with little change. Provider-specific settings, custom authentication flows, admin workflows and any scripted extensions must be rebuilt by hand. The check is a successful sign-in test per client against the new platform in a non-production environment, with token claims compared field by field against the old ones.
Plan the credential and session transition
Decide how user passwords move. Some platforms can import password hashes, others can only force a reset or use lazy migration on first login. Confirm the import formats and hash algorithms with the vendor before committing to a method, because this depends on the product version and the deployment. Also plan session lifetimes and MFA enrollment, so users are not unexpectedly signed out. The output is a written decision per user source, approved by security.
Run both platforms in parallel
Keep the old platform live while the new one serves a pilot tenant or internal users. Route test sign-ins to both, compare audit logs, failed login rates and token contents, and fix mismatches in claim mapping or redirect handling. Run synthetic logins against each application on a schedule. The step is complete when the pilot shows no unexplained differences across the defined test cases and the rollback path has been exercised.
Cut over tenants one at a time
Move tenants in batches, starting with the lowest-risk customers, and update each application's issuer and client settings for that tenant only. Keep the old configuration available for rollback until the batch has run without incident. Support staff follow a written runbook for each batch. The cutover for a tenant is done when its users sign in on the new platform, its external identity providers still work, and the old tenant record is marked read-only.
Retire the old configuration
After the final tenant has been cut over and the agreed observation period ends, disable old clients, remove stored credentials that are no longer needed and archive configuration exports and audit records under the retention rules that apply. The identity owner confirms in writing that no application still points at the old issuer. This closes the migration and produces the evidence that the old platform can be decommissioned.
Where Keycloak and Logto projects usually run long
The most common delay on a Keycloak project is database and high availability design, settled late. Keycloak needs a relational database in production, and its high availability designs both depend on a synchronously replicated database, so the choice of PostgreSQL, Aurora PostgreSQL or another supported engine has to be made before the cluster is built. Upgrades add a second source of delay. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, and schema migration runs automatically at startup by default. Teams that want to review the SQL first should decide now whether they will use automatic or manual migration, and who signs off each upgrade window. On Logto, the equivalent surprise is the single-admin limit in self-hosted Logto OSS. By default only one administrator account exists, and adding more admin members requires a self-hosted license. If several engineers and an identity owner must administer the tenant, the buyer has to decide between buying that license and using Logto Cloud, which includes team management, before any build work starts.
Modeling tenants and customer identity providers is the work that most often runs longer than estimated. In Keycloak, the choice between realms and Organizations, and how each customer's SAML or OIDC identity provider is attached, determines how administration can be delegated. In Logto, organizations support organization RBAC, member invitations and just-in-time provisioning, and the roles and permissions must be designed before customers are onboarded. Customer SAML onboarding then needs its own test plan, covering each customer's metadata, attribute mapping, certificate rotation and a failed login path. The work needs a platform engineer for database, cluster and upgrade design, an identity owner who decides the tenant and role model, and a security reviewer who signs off SAML trust and admin access. A fixed-scope engagement would define these in writing before work starts: the database and HA target, the upgrade approval process, the tenant and customer identity provider model, the SAML test cases and the handover items.
Questions buyers ask before choosing Keycloak or Logto
How much does it cost to run Keycloak or Logto yourself?
Both server licenses are free to use, so the cost is in the infrastructure, the database and the people who run them. Keycloak is Apache-2.0 and needs a relational database in production, with PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL among the supported options, according to the Keycloak database guide. Self-hosted Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0, and the docs recommend at least 2 vCPU, 8 GiB of memory and 256 GiB of disk. Drivers that raise cost on either side include high availability, the number of environments, backup and upgrade frequency, and whether you need a managed database service. Ask any vendor or partner for a quote that lists each infrastructure item, who pays for it, what recurs monthly and what is a one-time setup charge.
How long does a typical self-hosted identity setup take?
The duration depends on scope, and no supplied figure gives a typical timeline, so confirm it against a written scope. The main variables are the number of applications to integrate, whether you broker logins to external identity providers, whether you federate users from LDAP or Active Directory, and how many environments you need. Your team must supply a cloud or data center target, a production-grade database, DNS and TLS certificates, an identity owner who approves claims and roles, and test accounts for each application. For Keycloak on Kubernetes, the Keycloak Operator is installed through Operator Lifecycle Manager or kubectl, so your platform team must already run that cluster. Ask for a milestone plan with entry and exit criteria for each phase.
Can an internal team run Keycloak or Logto without outside help?
Yes, many internal teams run either product, but the answer depends on skills you already have. Keycloak asks the operator to manage a relational database, high availability design, Operator update approval and, for upgrades, a choice between automatic schema migration at startup and manual SQL migration that the upgrading guide suggests for large deployments. Logto OSS asks for Node.js and PostgreSQL operations, and its docs warn against using the bundled Docker Compose setup in production because that database is recreated on each run. Assess whether your team can own patching, backups, monitoring and incident response for the identity service, since login outages affect every product. Many organizations buy a fixed-scope implementation for setup and hardening, then keep support in-house or on a retainer.
Does self-hosted Logto OSS really allow only one admin?
By default, yes: self-hosted Logto OSS supports only one administrator account, according to the Logto OSS getting started documentation. Adding more admin members requires a self-hosted license, while Logto Cloud includes team management. This matters for separation of duties, because a single administrator account means shared credentials or a single point of control over tenants, applications and connectors. Confirm the current license terms and the admin model directly with Logto before you rely on it, since the license governs what you can add. Keycloak has no equivalent per-admin limit in its Apache-2.0 distribution, so access to its admin console is governed by your own realm and role configuration.
Can Keycloak handle B2B tenants the way Logto organizations do?
Keycloak can model B2B customers, but its tenancy model differs from Logto's. Logto lists organizations with organization RBAC, member invitations and just-in-time provisioning as built-in features, according to the Logto README. Keycloak uses realms for isolation and offers an Organizations feature for grouping users under a customer, so you must test how much of your B2B flow it covers. Ask each vendor to demonstrate per-customer login, invitation, role delegation and identity provider configuration in a proof of concept built on your own tenant model. Note that Keycloak realms add operational weight when you run many isolated tenants, because each realm carries its own configuration.
How hard is it to switch from Keycloak or Logto later?
Switching is possible but costs more the longer you wait, because user data, password hashes, client registrations and integration code all live in the identity layer. Both products use standard protocols, with Keycloak supporting OpenID Connect, OAuth 2.0 and SAML 2.0 and Logto stating full support for OpenID Connect, OAuth 2.1 and SAML, so application-side code is portable in principle. The harder parts are user migration, since password hashes and MFA enrollment may not transfer cleanly, and rewriting custom authentication flows. Keep your claims and roles in a documented model, export configuration regularly, and keep your database under your own backup policy. Ask any implementation partner to state in the written scope how they will handle data export and cutover.
Which product should I check first for a SaaS login project?
Start with the operational model you can sustain, then check licensing and tenancy against your product plan. Keycloak suits teams that need an established Apache-2.0 server with SAML, LDAP and Active Directory federation, an admin console and a documented high availability path. Logto suits teams that want a developer-oriented CIAM product with organizations built in and whose budget and admin needs fit an MPL-2.0 open source core and the single-admin default. Run a short proof of concept against your three most important flows, record the operator hours it took, and compare that with the written scope from each source before choosing.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Keycloak or Logto decision, we start from your tenancy model, login flows and hosting constraints, then write down the scope before any work begins.
How we scope
- We confirm whether you need B2B tenant organizations, SAML for enterprise customers, or a single login for internal apps.
- We record the database, hosting platform, and admin account model you need, including whether a self-hosted Logto admin limit matters.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install and configure the chosen platform in your infrastructure, with a production database rather than a development file store.
- We integrate OIDC, OAuth and SAML clients for your applications and test the login, logout and tenant-isolation paths.
- We run security testing against the identity layer and document the findings and fixes before go-live.
How we hand over
- You receive architecture, configuration and runbook documentation covering backups, upgrades and disaster recovery steps.
- We walk your engineers through admin tasks, client onboarding and how to review changes to tenant and login settings.
- We prepare the evidence your compliance assessor may ask for, while independent auditors issue any audit report or certification.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover tracking of new Keycloak or Logto releases and planning of upgrade windows in your environment.
- Ask us to confirm support terms, response expectations and upgrade scope in the written quote.
