Keycloak or Casdoor: when each one fits
Choose Keycloak when you need an enterprise SSO hub that sits in front of many applications, federates existing directories and runs under a formal database and high availability standard. Choose Casdoor when you need a lighter identity server for a multi-organization application, especially one that must speak CAS or RADIUS to legacy systems. The decision turns on four questions: which protocols your systems actually require, how many organizations must share one instance and how isolated they must be, which production databases your standards allow, and which team will operate the server day to day.
Start with protocols. Keycloak covers OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external OIDC or SAML providers, and federates users from LDAP or Active Directory. Casdoor also speaks CAS, LDAP, SCIM 2.0 and RADIUS, so if a network appliance or an older application needs CAS or RADIUS, confirm that Keycloak meets the need through another component before you assume it does. List every protocol and every consumer in a short inventory, then check each one against the current documentation for both products.
Then check the operating model. Keycloak requires a relational database in production, documented for PostgreSQL 14 to 18 and several other engines, and it documents high availability designs that depend on a synchronously replicated database. Ask your DBA which engines are approved, who owns upgrades and backups, and whether your team can carry Keycloak's four releases a year. Casdoor supports MySQL, PostgreSQL, SQLite and SQL Server, and Casdoor Cloud is an option if you do not want to run the server yourself. Confirm the support and data residency terms directly with the Casdoor team before relying on either.
Which platform fits which scenario
This table maps common scenarios to the platform that fits them better and the condition that makes it so. Read each row as a decision rule, then check the condition against your own estate, since the right answer often depends on protocols, database choice and who operates the server.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Enterprise workforce SSO across many internal apps | Keycloak | Choose Keycloak when the estate depends on SAML 2.0 and OIDC integrations, LDAP or Active Directory federation, and a mature admin console, and when your team can operate a relational database and clustered deployment. |
| B2B SaaS product with many customer organizations | Casdoor, or Keycloak if organizations need strict isolation | Casdoor runs several organizations in one instance, each with its own users, groups, roles, applications and branding. Confirm whether per-customer isolation, delegated administration and per-customer identity providers meet your requirements in both platforms before deciding. |
| Legacy consumers that speak only CAS | Casdoor | Casdoor is documented as a CAS server, so CAS-only applications can sign in against it directly. Keycloak's documented protocols in this comparison are OpenID Connect, OAuth 2.0 and SAML 2.0, so CAS clients would need a different route. |
| Legacy consumers that speak only RADIUS | Casdoor | Casdoor's documentation describes serving RADIUS for systems that support only that protocol. Keycloak's documented protocols do not include RADIUS, so confirm any Keycloak bridge with the vendor before planning around it. |
| Small team running a single product | Casdoor, if the product needs a lightweight multi-org login | A single product with few protocol needs is simpler on Casdoor's Go service with a web console. Keycloak fits when the team already runs it or expects enterprise integrations to grow. |
| Air-gapped or regulated estate | Keycloak, usually | Both are Apache-2.0 and can run self-hosted. Keycloak's documented production database list and high availability designs give a wider, well-documented operating base. Confirm Casdoor's database, backup and upgrade support against your own controls before choosing it. |
| Teams that need a managed service as an option | Casdoor, with Casdoor Cloud as a path | Casdoor Cloud runs a dedicated instance and database kept up to date by the Casdoor team. Keycloak's documentation covers self-hosting; confirm which managed Keycloak offerings your provider supports. |
How Keycloak and Casdoor are built and deployed
Keycloak and Casdoor make different trade-offs in how they are built, which database they expect and how they grow. The cards below cover each part of the stack and what it means for running, upgrading and backing up the server in your own infrastructure.
Keycloak as a Java server
Keycloak is a Java server that runs from its own distribution on virtual machines or inside Kubernetes. Its admin console, protocol endpoints and realm configuration all live in the same process, so a platform team manages one product with a defined release cadence. Keycloak plans four minor releases a year, and its project says breaking changes in a minor release are opt-in. Check which upgrade path your team can staff before committing, since the upgrade procedure depends on your build and realm data.
Required relational database for Keycloak
Production Keycloak needs an external relational database, and the supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. The bundled dev-file database is for development only. Your backup, restore and database patching routines therefore sit with the database team, not inside Keycloak. Confirm which database engines your DBA team already supports, because that choice drives your backup tooling and your disaster recovery plan.
Keycloak high availability designs
Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments without an external Infinispan cluster, and the deprecated multi-cluster v1 design. Both supported designs require a synchronously replicated database, so the database is part of your availability target. Ask your team to test failover against their own load before relying on a clustered design, since the documentation does not replace your sizing work.
Keycloak Operator for Kubernetes
The Keycloak Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources and is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. The Operator does not provide your database, so you still own its backups and sizing. Keycloak's documentation strongly recommends manual approval mode for operator updates to avoid unintended upgrades, which fits a change-controlled environment.
Casdoor Go backend and React console
Casdoor's backend is written in Go on the Beego framework, and its web console is written in React. A single Go service delivers the identity server and console, which keeps the runtime footprint small and the build pipeline simple. Your team should check whether its Go and React toolchain fits its patching and vulnerability scanning process, and confirm how Casdoor's release notes handle breaking changes between its frequent minor releases.
Casdoor databases and SQLite for small setups
Casdoor stores data through XORM, which supports MySQL, PostgreSQL, SQLite, SQL Server and other databases. SQLite is a practical choice for a small evaluation or a single-node lab, where it removes a database server from the design. For enterprise use, confirm the database engine you intend to run, your backup method and whether your DBA team will support it. Ask Casdoor for its guidance on clustering and high availability, because those features were not documented in the sources reviewed for this page.
Which protocols and identity sources each one covers
Keycloak covers the protocols most enterprise SSO programs start from: OpenID Connect, OAuth 2.0 and SAML 2.0 for applications it serves directly, plus identity brokering to external OIDC or SAML providers and LDAP or Active Directory user federation, where Keycloak reads users from an existing directory. Those two identity sources work differently. Brokering hands the login to an upstream provider, while federation keeps the directory as the source of user records and lets Keycloak authenticate against it. Before you shortlist either product, list every application in your estate and the exact protocol each one uses, then mark which ones need SAML, which need OIDC and which depend on LDAP or RADIUS.
Casdoor lists a wider set of protocols in its README: OAuth 2.0, OpenID Connect, SAML 2.0, CAS, LDAP, SCIM 2.0, WebAuthn, TOTP MFA and MCP. Its documentation positions it as an OAuth 2.0 and OIDC provider, a SAML identity provider and a CAS server, and notes that the CAS server also serves LDAP and RADIUS for systems that only support those protocols. That makes Casdoor the more natural candidate when legacy applications speak CAS, or when RADIUS-only network devices or LDAP-only tools need a front door. Its syncers can import users from LDAP, Active Directory and Keycloak, so a migration or coexistence period can start from an existing directory. Ask Casdoor's maintainers or test in your own environment whether each specific application's CAS, RADIUS or SAML flavor works, including attribute mapping and logout behavior.
Feature comparison on protocols, tenancy and operations
This table sets Keycloak and Casdoor side by side on licensing, protocols, multi-organization design and day-two operations. Read each row as a fit question: a check mark or cross only appears where the answer is settled by the supplied documentation, and rows marked to confirm need a direct answer from the vendor before you decide.
| Capability | Keycloak | Casdoor |
|---|---|---|
| License | Apache-2.0 (Keycloak LICENSE file) | Apache License 2.0 (casdoor/casdoor repository) |
| Core protocols | OpenID Connect, OAuth 2.0 and SAML 2.0, with identity brokering to external OIDC or SAML providers | OAuth 2.0, OpenID Connect, SAML 2.0, CAS, LDAP, SCIM 2.0, WebAuthn, TOTP and MCP |
| CAS and RADIUS | Not listed among supported protocols; confirm with the vendor if legacy CAS or RADIUS clients are in scope | CAS server supported; RADIUS served for systems that only support that protocol |
| SCIM | Confirm with the vendor and current docs before relying on it for provisioning | SCIM 2.0 listed in the README |
| LDAP role | Federates users from LDAP or Active Directory (Keycloak reads the directory) | Serves LDAP to apps that need it and syncs users from LDAP, Active Directory and Keycloak |
| Multi-organization model | Realms as isolated tenants, plus an Organizations feature for B2B customers; confirm the fit for your tenant count | Several organizations share one instance, each with its own users, groups, roles, applications and branding |
| Production databases | PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL; dev-file database is not for production | MySQL, PostgreSQL, SQLite, SQL Server and other databases through XORM; confirm which are supported for production |
| High availability documentation | Documented single cluster across zones and multi-cluster v2 designs, both requiring a synchronously replicated database | Confirm HA guidance with the vendor; not covered in the supplied documentation |
| Kubernetes install | Keycloak Operator via Operator Lifecycle Manager (recommended) or kubectl; manual approval mode advised for updates | Confirm container and Kubernetes deployment options with the vendor |
| Admin console and release cadence | Admin console included; four minor releases a year since Keycloak 26.0, current release 26.8.1 | Web console included; releases tagged in GitHub, with v4.21.0 published October 18, 2026 |
Apache-2.0 licensing and what is paid for each
Keycloak is licensed under Apache-2.0, as stated in the project's LICENSE file, and the community project is free to download, run, modify and redistribute under those terms. The project is a Cloud Native Computing Foundation incubating project, and it publishes releases on its own schedule. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it says breaking changes in a minor release will be opt-in. The current release is 26.8.1, published October 13, 2026.
- No licence fee: The Apache-2.0 licence carries no per-user or per-node charge for the community server.
- Release cadence: Four minor releases a year means regular upgrade work, so budget time for testing each one.
- Opt-in breaking changes: Minor upgrades are designed to avoid surprises, but you still need to read the upgrading guide before each move.
- Your own support: The community project has no support contract. Your team, or a partner you hire, carries patching, incident response and upgrades.
Ask your implementation partner or internal team which Keycloak versions they will support and how long each one is maintained before you commit to a version.
Red Hat build of Keycloak is Red Hat's supported distribution based on the open source Keycloak project. It replaces Red Hat Single Sign-On, and it is a separate product from the upstream community release. Red Hat's product page showed version 26.6 as its latest at the time of research, so confirm the current build on the vendor page before you plan around it. The licence and source of the upstream code remain Apache-2.0, but the supported build, its support terms and any subscription are Red Hat's to define.
- Separate distribution: It is a supported product, not the same artifact as the upstream release, so version matching matters when you move between the two.
- Subscription support: Support, patches and lifecycle commitments come from a Red Hat subscription, which is a recurring cost.
- Platform fit: It suits organizations already standardized on Red Hat platforms and support contracts.
- Lifecycle terms: Check the support window for the exact build you deploy, not only the headline version.
Ask Red Hat for the subscription tiers, the support windows for the build you plan to run, and what is included in the subscription beyond the server itself.
Casdoor is licensed under the Apache License 2.0 and describes itself as a single sign-on and authentication server with a web console. The open source server is free under those terms, and it runs with your own database. Casdoor v4.21.0 was published on October 18, 2026, after v4.20.0 on October 11 and v4.19.0 on October 10, which shows a fast release pace. Frequent releases mean your team carries the upgrade and testing workload that comes with them.
- No licence fee: The Apache-2.0 server carries no licence charge.
- Fast release pace: Three releases in about eight days in October 2026 shows how often you may need to test and upgrade.
- Your own operations: Hosting, database backups, patching and upgrades fall on your team or your partner.
- Commercial support: No commercial support tiers were supplied for the open source server. Confirm with the Casdoor team whether paid support exists and what it covers.
Ask the Casdoor team what support, response commitments and upgrade assistance are available for a self-hosted deployment, and in writing.
Casdoor Cloud is the hosted option run by the Casdoor team. It runs a dedicated Casdoor instance and database kept up to date by the Casdoor team, so you give up control of the hosting environment in exchange for less operational work. New accounts receive 20 US dollars in free credit, according to the Casdoor README. That credit is a starting allowance for evaluation, and it does not show what production use costs. Pricing after the credit, and the terms that apply to your data, need to come from Casdoor directly.
- Dedicated instance: Your instance and database are separate from other customers, which the README describes.
- Managed upgrades: The Casdoor team keeps the instance current, which removes a recurring task from your team.
- Free credit: New accounts get 20 US dollars of credit, useful for trial work only.
- Hosting location: Confirm where data is stored and whether that meets your residency and regulatory needs.
If you handle regulated data, ask Casdoor for the terms of service, the data processing terms, the post-credit price and the exit process for moving data out.
Database choices and multiple organizations per instance
Keycloak needs a relational database in production, and the supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only and should never back a production realm. Casdoor takes a different route: it stores data through XORM and supports MySQL, PostgreSQL, SQLite, SQL Server and other databases. For a team that already runs one approved engine, the first check is whether that engine sits on Keycloak's supported list, or on Casdoor's broader list, and whether your DBA team will support it at the versions you need. Confirm the exact Casdoor database support matrix with the Casdoor project before you standardize on it.
The two products also model tenancy differently. In Keycloak, a realm is the isolation boundary: each realm holds its own users, clients, roles, identity providers and login themes, and Keycloak's Organizations feature adds B2B membership inside a realm. In Casdoor, several organizations share one instance, and each organization gets its own users, groups, roles, applications and branding. Casdoor's model is lighter to operate, because one deployment and one database serve many tenants. Keycloak's model costs more per tenant but isolates administration, signing keys and configuration more strictly. Isolation per realm matters more than density when a regulator, a customer contract or an internal audit requires that one tenant's administrators, client secrets or login policies cannot touch another's.
Before you choose, run a short test that matches your real tenant count and admin model. Create two sample tenants on each platform, delegate an administrator to one of them, and confirm that the delegated administrator cannot read or change the other. Then record how backups, restores and schema upgrades would apply to all tenants at once, since a shared database and shared instance mean one failure or one bad upgrade touches every organization. This is a decision check, not a benchmark, and the result should be written into your design record before procurement.
What drives the running cost of each
Infrastructure is the cost you can most directly size, and it differs between the two platforms mainly in the database and the number of moving parts. Keycloak needs a relational database in production, and its supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and others. Its documented high availability designs both depend on a synchronously replicated database, so a highly available Keycloak estate carries a database cost of its own. Casdoor stores data through XORM in MySQL, PostgreSQL, SQLite, SQL Server and other databases, so the database choice is also open, but you should confirm which database and replication setup Casdoor supports for your availability target.
- Database engine and licensing: Ask which database edition each option requires, including any paid database license, support contract or cloud service fee.
- High availability sizing: Keycloak's supported designs multiply node count, load balancing and database replication. Ask the vendor or partner to size each tier against your load.
- Backup and disaster recovery: Backup storage and restore testing recur over time and grow with data volume and retention.
- Hosting location: Cloud accounts, data centers and air-gapped networks each carry different infrastructure fees, which DeployOpen would scope within the client's own environment.
- Environments: Staging and test copies of the identity service double much of the footprint, so include them in the quote.
Before comparing totals, confirm the minimum production topology each platform needs for your availability target and price both on the same database and region.
Most of the recurring cost is people time, and the effort depends on the platform team's existing skills. Keycloak's Operator is installed through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, and it manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. Running it well assumes Kubernetes operating experience, and a team without that skill will either train or pay for it. Teams that run Casdoor as a single Go service with a web console may need fewer specialist hours for routine work, but they still own integration, hardening and backups.
- Kubernetes and Operator skills: A Keycloak estate on Kubernetes needs people who understand the Operator, cluster discovery and database connectivity.
- Identity expertise: Realm, client, federation and protocol configuration takes time from engineers who understand OIDC, SAML and LDAP, whichever platform you choose.
- Integration work: Each application onboarded, LDAP source connected or syncer configured is recurring project effort until the pattern is stable.
- Security review: Hardening, reviewing configuration changes and answering audit questions are ongoing tasks.
- Vendor or partner support: Retainers and fixed-scope engagements both carry fees, so ask what is included in each.
Ask each shortlisted option to describe the roles it expects to staff and the hours it assumes for routine operations, then compare that against the skills you already have.
Upgrade cost depends on how often a platform changes and how much testing each change needs. Keycloak has planned four minor releases a year since Keycloak 26.0, with breaking changes in a minor release made opt-in, and it migrates the database schema automatically at startup by default. Its Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. Those points mean a steady, predictable upgrade cycle that you still have to test and schedule. Casdoor publishes frequent releases, including v4.19.0, v4.20.0 and v4.21.0 within a single month in October 2026, so you should confirm which of those releases carry breaking changes and how long each line receives fixes.
- Minor release cadence: Four minor releases a year means recurring test cycles, not one large project every few years.
- Schema migration: Automatic migration at startup is convenient, but large deployments may prefer manual SQL applied by administrators, which adds planning time.
- Operator approval: Manual approval mode keeps upgrades under your control and adds a step to each release.
- Release support windows: Ask how long each release line is patched, since that sets how often you must move.
- Customization drift: Custom themes, providers or code need retesting on every upgrade.
Ask for the upgrade procedure, the rollback steps and the number of upgrades per year the quote assumes.
Both platforms are Apache-2.0 licensed, so the software itself carries no license fee for either. The running cost comes from services and from any paid distribution you choose. Keycloak is licensed under Apache-2.0, and Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project, replacing Red Hat Single Sign-On, which means a Red Hat subscription is a separate cost if you choose it. Casdoor is also Apache 2.0, and Casdoor Cloud runs a dedicated instance and database kept up to date by the Casdoor team, with new accounts receiving 20 US dollars in free credit according to the Casdoor README. That is a managed service fee instead of a self-hosting cost, and it recurs with usage.
- Software license: Apache-2.0 for Keycloak and Casdoor means no license fee for the core server.
- Vendor distribution: A Red Hat subscription is a recurring cost if you need its support and certified builds.
- Managed hosting: Casdoor Cloud shifts infrastructure and upkeep to the provider, and that fee recurs.
- Support contracts: Vendor support, paid database support and partner retainers each add recurring spend.
- Services: Initial implementation is typically one-time, while retainers for upgrades and testing recur.
For each option, ask which parts of the quote are license fees, which are support, which are cloud charges and which are one-time services.
Moving from Keycloak to Casdoor or the reverse
This sequence moves identities and applications between Keycloak and Casdoor without breaking live logins. It ends with one tested cutover per application and a retired source instance that no application still calls.
Inventory clients, protocols and dependencies
List every application that signs in against the current instance, and record the protocol each one uses: OpenID Connect, OAuth 2.0, SAML 2.0, CAS, LDAP or RADIUS. Note the redirect URIs, token lifetimes, claims, group mappings and any service accounts. Owners of each application confirm the list. The output is a signed-off inventory with one row per client, which becomes the checklist for the rest of the work.
Map realms or organizations to the target model
Keycloak groups identities into realms, while Casdoor groups them into organizations inside one instance, each with its own users, groups, roles, applications and branding. Decide which realms become which organizations, or whether several realms merge into one organization. Record how roles and groups translate, because Casdoor's role model will not match Keycloak's realm roles one to one. The output is a written mapping table reviewed by the identity team.
Export users and credentials where supported
Casdoor syncers can import users from systems such as LDAP, Active Directory and Keycloak, so start there for accounts. Confirm with the Casdoor documentation and your own test instance which user attributes, group memberships and role assignments the syncer carries across. Ask the vendor or your integrator whether password hashes can be moved and whether they stay usable. Treat stored credentials and MFA enrollments as unconfirmed until a test import proves them. The output is a test import report with counts and gaps listed.
Re-register applications on the target instance
Configuration does not transfer automatically, so create each application, client, redirect URI, signing certificate and scope on the target platform by hand or through scripts your team maintains. Keep client secrets in a secrets manager rather than in configuration files. Mark each application as ready only after its owner confirms the settings. The output is a register of target applications with status and the owner who approved each one.
Test each protocol flow end to end
For every application, run sign-in, token refresh, logout, group or role claim checks and any single sign-on from another application. Test each protocol separately, including SAML assertions and CAS or LDAP or RADIUS paths if they are in use. Run the same tests against the source instance to compare results. Record failures and fix them before the next test. The output is a signed test log per application and protocol that shows the expected and actual results.
Cut over applications in controlled batches
Switch applications to the target instance in small groups, starting with low-risk internal applications and leaving production customer or privileged systems for later. Keep the source instance available so an application can be pointed back if a flow fails. Watch sign-in errors and support tickets after each batch. The output is a cutover record showing the date each application moved and any rollback that occurred.
Retire the source instance safely
Once no application calls the source instance and logs show no remaining traffic, disable its clients, revoke its signing keys and stop its services. Confirm that backups meet your retention policy before deleting data, and record where the final export is stored. Remove DNS entries, load balancer routes and monitoring for the old instance. The output is a decommissioning record signed by the identity owner and the application owners.
What implementing each one involves and where projects run long
Implementing Keycloak in production starts with the database, not the login screen. Keycloak needs a relational database in production, and the default dev-file database is for development only, so the first decision is which supported engine your operations team can back up, patch and restore. Next comes the high availability design, which the project documents as a single cluster spread across availability zones or the multi-cluster v2 design, and both assume a synchronously replicated database. TLS termination, hostname settings, admin console access and hardening of the admin account are usually scoped in the same sprint. For Casdoor, the equivalent foundation work is a supported database such as MySQL or PostgreSQL, a deployment model you can patch yourself, and a plan for the initial organization and admin setup. Confirm the Casdoor release process and upgrade path with the vendor and your own environment before you commit to a timeline.
Application onboarding and MFA policy take more effort than the server install in most projects. Each client needs its redirect URIs, scopes, claim mappings and session settings recorded, and Keycloak's Operator can manage clients as code through KeycloakOIDCClient and KeycloakSAMLClient resources if your team runs Kubernetes. Directory federation adds a second workstream: mapping LDAP or Active Directory attributes, deciding whether passwords stay in the directory, and testing group-to-role mapping with real accounts. Casdoor's syncers can import users from LDAP, Active Directory and Keycloak, which helps migration but still needs an attribute review. Backups must cover the database and any exported realm or organization configuration, and restore should be rehearsed, not assumed.
Projects run long in three predictable places. The first is legacy CAS or RADIUS clients: confirm each client's exact protocol version, attribute expectations and certificate handling before promising coverage, because Casdoor's CAS and RADIUS support is a stated feature, and those clients often break on details rather than on the protocol. The second is governance across many realms or organizations: Keycloak administrators typically separate realms, while Casdoor places several organizations in one instance, so decide early who administers each tenant, how branding and applications are isolated, and how an audit of administrative changes is produced. The third is integrations that need custom claim or attribute mapping, where each mapping is one more item to test on every upgrade. Ask any implementation partner for a written scope that lists these items individually.
Questions buyers ask before choosing Keycloak or Casdoor
Can Casdoor replace Keycloak for enterprise SSO?
It can for some enterprise SSO scenarios, but the answer depends on what the SSO hub must do. Casdoor speaks OAuth 2.0, OpenID Connect, SAML 2.0, CAS, LDAP, SCIM 2.0, WebAuthn and TOTP MFA, and it can import users from LDAP, Active Directory and Keycloak. Keycloak has a longer record as the central SSO server for large workforce estates, with brokering to external OIDC or SAML providers and LDAP or Active Directory user federation as core features. Before you decide, list every application that must sign in, the protocol each one uses, and the directory it reads from. Then test the exact federation, provisioning and session behavior you need in a non-production Casdoor deployment, and compare the result with your Keycloak requirements.
Does Keycloak need a dedicated database administrator?
Not always, but someone on your team must own the database. Keycloak needs a relational database in production, and it supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and other engines listed in the database guide. Keycloak migrates its schema automatically at startup by default, and it also supports manual migration, which the upgrading guide suggests for large deployments. Backups, patching, sizing and high availability are your responsibility, and multi-cluster designs require a synchronously replicated database. Casdoor also uses a relational store (MySQL, PostgreSQL, SQLite, SQL Server and others through XORM), so the database skill need is similar. Confirm the skills your team has before you choose the engine.
How does multi-organization tenancy differ between Keycloak and Casdoor?
Casdoor lets several organizations share one instance, each with its own users, groups, roles, applications and branding. Keycloak models tenants with realms, which isolate users, clients and configuration, and its Organizations feature covers B2B membership inside a realm. The practical difference is the administrative boundary. If you run a small number of customer-facing applications with separate user pools, Casdoor's per-organization model may be simpler to set up. If you need strict isolation, many distinct identity providers per tenant, or a large number of realms managed through automation, confirm how each product handles delegated administration and per-tenant configuration in a proof of concept. Test a realistic tenant count with your own applications.
Is Casdoor Cloud enough, or do we need to self-host?
Casdoor Cloud is enough when your data location, network rules and change control allow a hosted service, and self-hosting is needed when they do not. Casdoor Cloud runs a dedicated Casdoor instance and database that the Casdoor team keeps up to date, and new accounts receive 20 US dollars in free credit according to the project README. Self-hosting keeps the identity store, keys and logs inside your own cloud account, data center or air-gapped network, and it puts patching, backups, high availability and incident response on your team or on a support partner. Confirm the hosted terms, data residency, backup and recovery commitments in writing with Casdoor before you rely on them.
What does the implementation work require from our own team?
Your team provides the decisions and the access, and the implementation partner or internal engineers do the build. Expect work on the target platform, database, certificates, DNS, directory connections, application client registrations, MFA policy and logging. Keycloak in production adds a database, a clustering design and an upgrade process, and Keycloak's release plan includes four minor releases a year, so someone must own patching. Casdoor is a Go server with a React console, so the same questions apply with a smaller footprint in some areas. Most engagements are fixed-scope, so ask for a written list of applications, protocols, directories and acceptance tests before you agree on deliverables and timelines.
How do we confirm CAS or RADIUS support for a specific application?
Check the application's own documentation for the exact protocol version, the attributes it reads, and how it handles the ticket or session flow, then test that flow against your Casdoor version. Casdoor's documentation describes it as a CAS server that also serves LDAP and RADIUS for systems that only support those protocols, and the README lists CAS among its protocols. Support for a protocol in general does not prove support for your application's version, binding method or attribute mapping. Build a test case with a representative user, a group membership and a failure scenario, run it against the release you plan to deploy, and record the results. Keycloak does not list CAS or RADIUS among its supported protocols in the supplied facts, so confirm any legacy requirement with the Keycloak documentation or a gateway in front of it.
Which release should we plan around for Keycloak and Casdoor?
Plan around the release you will actually deploy, and check the current release notes before you commit. Keycloak 26.8.1 was published on October 13, 2026, and since Keycloak 26.0 the project plans four minor releases a year, with breaking changes in minor releases opt-in. Casdoor v4.21.0 was published on October 18, 2026, after v4.20.0 and v4.19.0. Because both projects release often, record the version you test, the upgrade path you rehearse and the owner of each patch cycle. Ask your vendor or partner how they will track security fixes between releases.
How DeployOpen helps you choose and implement
DeployOpen helps teams decide whether Keycloak or Casdoor fits their identity estate, then plans, implements and hands over the chosen platform inside your own infrastructure. We start from your protocol list, user sources and tenancy model, so the recommendation rests on what your applications actually need.
How we scope
- We list every application, protocol (OIDC, SAML, CAS, LDAP, RADIUS) and user source that must authenticate against the new platform.
- We record whether you need one enterprise SSO hub or many isolated organizations, and who administers each one.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen platform in your cloud accounts, data centers or air-gapped network, with the database you select.
- We configure identity brokering, directory sync or federation to your existing LDAP or Active Directory sources.
- We test login flows, token handling, MFA and admin delegation against the scoped application list before go-live.
How we hand over
- We document the architecture, configuration, database backup approach and the upgrade path for your chosen release line.
- We prepare access control, logging and configuration evidence that your auditors or compliance team can review.
- We walk your administrators through daily operations, user onboarding and client registration so the team can run the platform.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We plan upgrades against each project's own release notes and test them in a staging environment before production.
- Ask us to confirm in writing which protocol gaps, licensing terms and database versions apply to your environment before you commit.
