Why an Amazon Cognito alternative outside AWS changes the login design
If your product must run in a customer's datacenter, on premises or on another cloud, the login layer has to move with it. Self-hosted Keycloak, ZITADEL and Ory can run wherever the product runs, because each is software you deploy in the environment you choose. The real question is not whether an open-source identity server can run outside AWS, but which one fits the protocols, tenancy model and operating model your product needs. A Cognito user pool is a managed service tied to an AWS Region, so the login for a product deployed in several places sits in one pool that your customers' systems must reach. Confirm against current AWS documentation whether that fits each deployment model, including air-gapped sites, customer clouds and data residency rules. Whatever the answer, the pool becomes a dependency your product must reach from every environment, and that dependency shapes the design.
The short answer is that Keycloak is the broadest general-purpose choice for OpenID Connect, OAuth 2.0 and SAML 2.0, with built-in user federation to LDAP and Active Directory. ZITADEL fits multi-tenant products that need instances, organizations and projects isolated inside one system, and it runs on PostgreSQL 14 or later. Ory suits teams that want API-first identity and will build their own login interface, with the enterprise license covering features such as SAML and SCIM. Each choice changes who builds the login pages, who runs the database and who patches the service. Before you pick one, write down three answers: which protocols your customers' identity providers require, whether each customer needs its own isolated tenant, and who will operate the service after go-live, whether your own platform team, your customer or a partner. Those answers narrow the field faster than feature checklists, and they determine whether one login can span every deployment.
What a multi-deployment login must satisfy
When a product ships to a customer datacenter, another cloud and its own hosted environment, each deployment needs a login that behaves the same way. The requirements below connect the identity layer to the protocols, directories, databases and availability design that every deployment inherits.
One login across deployments
Each deployment should run the same identity server with the same realm, client and role definitions, so users and applications see one login model whether the product runs in AWS, on premises or elsewhere. A Cognito user pool is bound to one AWS Region, so a multi-environment product needs an identity service that you can install wherever the product runs. Check that your deployment packaging can version the realm configuration and promote it through environments without manual edits.
Standard protocols for every application
Applications should integrate through OpenID Connect and OAuth 2.0 for modern apps and SAML 2.0 for enterprise customers who still rely on it. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and ZITADEL implements the same set. Confirm that each protocol your customers require is supported by your chosen server and that the token claims your applications read, including the subject identifier, stay stable across deployments.
Federation with existing directories
Many customers already keep their users in LDAP or Active Directory, and they expect the product to authenticate against that directory instead of creating a second copy of every account. Keycloak has built-in user federation with LDAP and Active Directory servers, and ZITADEL can federate LDAP and OpenLDAP. Ask each customer which directory holds the source of truth, which attributes can be read, and whether accounts disabled in the directory must be blocked at login.
A production-grade database
The identity server stores users, sessions, clients and policies, so the database is part of your recovery plan for every environment. Keycloak supports PostgreSQL 14 to 18 among its production databases, and ZITADEL requires PostgreSQL 14 or later. The dev-file database that ships by default is for development only. Confirm which database your customers can operate, who runs backups, and how schema upgrades will be tested before they reach production.
High availability with replicated data
A login outage stops every user from reaching the product, so a customer-facing deployment usually needs more than one node. Keycloak's supported high availability designs both require a synchronously replicated database, which means the database tier, not only the application tier, must be sized and tested for availability. Ask who owns that database in each environment, what failover is expected, and how the design will be tested before a go-live.
Controlled upgrades across environments
Each deployment will receive identity server updates at a different pace, and an unplanned change to login behavior can lock users out. Keycloak plans four minor releases a year, and it says breaking changes in a minor release will be opt-in. Its Operator documentation strongly recommends manual approval mode for updates. Decide who approves upgrades per environment, keep a tested rollback path, and record the version each customer runs.
Which open-source option fits which deployment
This table compares Keycloak, ZITADEL and Ory Kratos with Hydra against the requirements that usually drive a move off Cognito, including protocols, tenancy, passkeys, SCIM, licensing and paid-tier features. Read each row as a question to put to the vendor, and confirm current feature availability in each project's documentation before deciding.
| Requirement | Keycloak | ZITADEL | Ory Kratos with Hydra |
|---|---|---|---|
| Licence | Apache 2.0 | AGPL-3.0 for core, Console and hosted login; APIs and SDKs Apache 2.0 | Apache-2.0 for open source components |
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 | OpenID Connect, OAuth 2.0 and SAML 2.0, plus SCIM 2.0 and LDAP | OpenID Connect and OAuth 2.0 through Hydra; SAML is an Ory enterprise feature |
| Multi-tenant organizations | Realms per tenant; confirm fit for many customer organizations | Instances, organizations and projects with data isolation | Organizations in Kratos are an enterprise feature |
| Passkeys | Supported; confirm the flow you need in the server guide | FIDO2 and WebAuthn passkeys with password fallback | Passkeys supported in Kratos, with your own login UI |
| SCIM provisioning | Confirm in current documentation | SCIM 2.0 service provider interface | SCIM is an enterprise feature, not in open source Kratos |
| Login page | Built-in admin console and themeable login pages | Built-in hosted login | API-first; you build the login UI yourself |
| Database | PostgreSQL 14 to 18 and other listed production databases | PostgreSQL 14 to 18 | SQLite, PostgreSQL, MySQL or CockroachDB for Kratos |
| Paid tier features | Confirm with Red Hat build of Keycloak support terms | Confirm hosted and enterprise options on the pricing page | Ory Enterprise License adds SAML, SCIM, organizations, CVE patch SLAs and 24/7 support |
| Operating effort | Clustered deployment, Operator and upgrade planning | PostgreSQL plus Docker Compose or Helm chart on Kubernetes | Separate services to run, plus your own UI and session code |
How to choose by product and customer situation
When one product ships into each customer's datacenter or private cloud, the identity service is installed as part of that product and runs with the same operational boundary. Keycloak is usually the best fit here because it is Apache 2.0 licensed, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and offers built-in user federation with existing LDAP and Active Directory servers. Customers often already run a directory, so federation matters more than a new user store.
- Directory federation: Confirm which LDAP or Active Directory attributes and group mappings each customer exposes, and test them in a lab.
- Upgrade path: Keycloak plans four minor releases a year, and you should decide how your product tracks them before shipping.
- Database choice: Check the supported production databases in the Keycloak database guide against what each customer already operates.
- Backup approach: The documented realm export and import has limits as a backup mechanism and requires all nodes to be stopped, so design your own backup and restore procedure.
- Operator approval: Use manual approval mode for operator updates if you deploy on Kubernetes.
Before committing, prototype a full install in a customer-like environment and rehearse an upgrade and a restore.
When each of your customers brings its own identity provider and needs isolation between tenants, ZITADEL is usually the closest fit. It organizes tenants as instances with full data isolation, organizations inside instances, and projects that group applications, roles and grants. It can federate with Entra ID, Okta, LDAP, Keycloak and any OIDC-compliant provider, and each customer organization can use a different identity provider.
- Tenant model: Map your customers to instances or organizations and check that the isolation level meets your contracts.
- License review: ZITADEL's core is AGPL-3.0, so have counsel confirm how that applies if you modify and distribute it with your product.
- Per-tenant federation: Test an OIDC and a SAML connection for two separate customer organizations at the same time.
- Provisioning: Confirm SCIM 2.0 behavior for the customer directories you need to sync.
- Database operations: Plan PostgreSQL 14 to 18 operations, including backups and failover, for the whole tenant base.
Before committing, prototype onboarding of two real-world-style test tenants with different identity providers and verify that a sign-in in one tenant cannot reach another.
When your team wants to own the login screens, flows and user experience, and needs identity as an API rather than a hosted login page, Ory is the option to evaluate. Ory Kratos handles identities with passwords, passkeys, social sign-in and TOTP through headless APIs, Ory Hydra provides a certified OAuth 2.0 and OpenID Connect server that works with your existing user system, and Ory Keto adds Zanzibar-style permissions. All of these are Apache-2.0 licensed.
- Build scope: Estimate the login, recovery, verification and MFA screens your team must build and maintain.
- Enterprise features: The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features outside the open source version, so confirm whether you need them.
- Support model: Ory states that open source suits evaluation and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Decide whether you need the Ory Enterprise License before you build on it.
- Permission model: Prototype your authorization rules in Keto before deciding how much logic lives there.
- Database: Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, so confirm your production choice.
Before committing, build one login flow end to end, including account recovery and MFA enrollment, and time how long your team needs to maintain it.
Some products do not need a full identity provider but must integrate with directories or protect internal web applications behind a proxy. In these cases authentik is worth a look because its free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, under the MIT-licensed open-source core. The free edition offers community support only, so plan your own support path.
- Protocol list: Confirm that you need LDAP, RADIUS or Kerberos specifically, and that the community edition covers them.
- Support gap: Community support is the only option in the free edition, so decide whether that suits your customers.
- Enterprise features: Google Workspace and Microsoft Entra ID integrations, and privileged access management, sit in the enterprise edition.
- Proxy scope: Test the proxy against each internal application's session and header requirements.
- Overlap: Avoid running two identity systems for the same users.
Before committing, confirm which protocols your customers' existing systems speak and run one proxied application in a test environment.
How to deploy one login across every environment
This sequence turns a Keycloak deployment into one identity layer that serves each on-premises site, customer datacenter or cloud environment with the same protocols, client definitions and recovery process. The output is a set of environments that sign users in consistently and can be rebuilt from versioned configuration.
Confirm protocols and clients for each deployment
Before any installation, list every application that will sign users in, the protocol each one needs (OpenID Connect, OAuth 2.0 or SAML 2.0), and the directories each deployment must read from. Product architects and the application owners should sign this inventory off together. The check is complete when every client has a named protocol, redirect URI pattern and owner, and when each deployment has a documented list of customer directories it must federate.
Choose the database and high availability design
Select a supported production database from the Keycloak database guide, such as PostgreSQL in the 14 to 18 range, and confirm the cluster design against the Keycloak high availability overview. Both supported designs need a synchronously replicated database, so ask the database team to confirm replication and failover behavior in writing. The step is complete when the architecture diagram names the database, the node count, the availability zones or sites, and who operates each component.
Deploy Keycloak with the method your platform uses
Choose Docker Compose or Kubernetes for the deployment target. On Kubernetes, the Keycloak Operator is installed through Operator Lifecycle Manager, which the Keycloak Operator documentation recommends, or with kubectl or the experimental Helm chart. Set the operator update approval mode to manual, as the documentation strongly recommends, so upgrades happen only after review. The check is complete when a test instance starts, serves its admin console over TLS and passes a sign-in test with a sample client.
Model realms and clients per deployment
Create the realm structure that matches your isolation requirements, with one realm per deployment or per tenant group, and define clients, roles and groups from the inventory in step one. Where your product ships clients through configuration, manage them as code with KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources if you run the Operator. The check is complete when each realm can be recreated from versioned files and the same client identifiers appear in every environment that uses them.
Federate customer directories and identity providers
Connect each environment to the directories it needs, such as LDAP or Active Directory through built-in user federation, and to any external identity providers that customers require over OIDC or SAML. Test with a small set of accounts from each source and confirm which attributes, group memberships and login names reach the application. Record the mapping for each federation link. The check is complete when a user from each directory signs in and receives the expected roles and claims.
Define a repeatable release process
Write a runbook that covers staging, test sign-in, change approval and rollout for every Keycloak upgrade. Keycloak plans four minor releases a year and says breaking changes in minor releases are opt-in, so read the release notes and the upgrading guide before each change. For large databases, decide whether schema migration runs automatically at startup or manually, as the upgrading guide describes. The check is complete when a staging environment has passed the same sign-in tests as production before each rollout.
Plan backups separately from realm export
Do not rely on realm export as your backup. The Keycloak server guide warns that the kc.sh export and import process has limitations as a backup and restore mechanism, and all nodes must be stopped while it runs. Instead, back up the database with a method your database team tests, and keep realm configuration in version control. Ask the vendor or your DeployOpen team to confirm the restore procedure against your own environment. The check is complete when a restore has been rehearsed in a separate environment and the recovery time is recorded.
Packaging identity with the product without locking each customer in
Shipping the identity service inside the product package means the vendor, not each customer, owns the Keycloak, ZITADEL or Ory version that runs at login. That choice simplifies installation, since a customer on a private network gets one tested bundle instead of assembling an identity stack. It also moves responsibility for upgrades and CVE patching onto your release process. Decide before you ship who is on the hook for a critical advisory against the bundled identity server, how quickly a fix reaches an air-gapped site, and whether the customer can take a patch without a full product upgrade. Write those answers into the support terms rather than leaving them for the first incident.
The alternative, having each customer run its own identity service, keeps the trust boundary and the user store where the customer already manages directories, but it multiplies the number of versions in the field. Each deployment then needs its own database backups, high availability design and patch window. Keycloak's own guidance is to treat upgrades carefully: its Operator documentation strongly recommends manual approval mode for operator updates, and its upgrading guide describes manual database migration for large deployments. Whichever model you pick, make the upgrade path a tested runbook and record which Keycloak or ZITADEL release each customer runs.
Ory's license split changes the patch calculus directly. The Ory Kratos README states that SCIM, SAML, organization login and CAPTCHAs are enterprise features not available in the open source version, and Ory says the open source servers suit evaluation and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Shipping open source Ory in a product therefore means accepting that your patch timing depends on your own monitoring of upstream releases, while the Ory Enterprise License adds timely CVE patches and 24/7 support SLAs. Confirm the current terms with Ory before you commit, because the split decides who guarantees the patch.
Evidence regulators and auditors ask for in this design
When a product runs its login on your own infrastructure, the evidence an assessor asks for shifts from a vendor's audit report to your own records. The six items below connect the architecture, configuration, recovery, administration, patching and federation of a self-hosted identity service. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any assessment.
Architecture and data location diagrams
Assessors want to see where user records, password hashes, sessions and signing keys live, which regions or datacenters hold them, and which networks can reach the identity service. For a replacement of Amazon Cognito, the diagram should show the database tier, the cluster nodes, the load balancers, the backup targets and every connected application. Confirm that the diagram matches the running environment, not the original design, and date it when it changes.
Configuration baselines for the identity service
A baseline records the settings that govern login: realm or instance settings, password and MFA policy, token lifetimes, redirect URI rules, allowed client types and TLS settings. Store the baseline as code or exported configuration under version control, so each change has an owner and a diff. Compare the running server against the baseline on a schedule and keep the comparison results as evidence.
Backup and restore test records
A backup only counts as evidence once a restore has been tested. Keep records of the database backups, the restore date, the environment used for the test and the time taken to bring logins back. Keycloak's realm export is not a complete backup mechanism according to its own documentation, and it requires all nodes to stop during the process, so the database-level backup and restore plan needs its own test record. Confirm the same for ZITADEL and Ory, which both depend on PostgreSQL or another database.
Access review logs for administrators
Administrators of an identity service can create users, change policies and issue tokens, so their access is among the most closely examined. Keep a current list of accounts with administrative roles, the approval for each grant, and periodic review records showing that unused or departed accounts were removed. Pair the review with admin event logs exported to your central log store, so an assessor can trace a privilege change to a named person.
Upgrade and patch records
Assessors look for a dated trail of what version ran, when it changed, who approved the change and how it was tested. Keycloak releases four minor versions a year according to its project plan, so a patch calendar and change tickets are needed. The Keycloak Operator documentation recommends manual approval for operator updates to prevent unplanned upgrades, and that choice should appear in the record as a documented decision.
Federation configuration
Each external identity source, such as LDAP, Active Directory or an upstream OIDC or SAML provider, is a trust decision and needs its own evidence. Record the endpoint, the certificate or signing key fingerprint, the attribute mapping, the sync schedule and the owner who approved the connection. Confirm which accounts can be disabled from the source directory and how a removed employee loses access to the application, since the identity service only inherits that state from the source.
Questions buyers ask before replacing Cognito outside AWS
What drives the effort and cost of moving off Cognito outside AWS?
The biggest drivers are the number of user populations, the number of applications that depend on Cognito tokens, and how much custom logic sits in Lambda triggers. Each app client, redirect flow and trigger must be rebuilt or re-pointed at the new issuer. Cost splits into a one-time part (design, migration, testing, cutover) and a recurring part (hosting, database, high availability, upgrades, support and staff time). Cognito's per-user pricing is only one line in the comparison. Ask any provider or partner for a quote that lists each component separately, including who carries the upgrade and patch work after go-live.
Can an internal team run Keycloak, ZITADEL or Ory on its own?
Often yes, but only if the team can own the operating work that Cognito currently hides. That includes a supported database such as PostgreSQL, a high availability design with a synchronously replicated database, backups and restore tests, certificate and secret handling, monitoring, and a planned upgrade path. Keycloak documents three high availability architectures and recommends manual approval for Operator updates. ZITADEL recommends Kubernetes with the official Helm chart for high availability. Ory's open-source edition is described by Ory as suited to evaluation and to deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Confirm which of these you need before you decide who operates the platform.
How long does a Cognito migration take, and what sets that duration?
No duration figures are available for this migration, so treat any timeline as something to agree in writing against a defined scope. The main factors are the number of user pools and users, whether passwords must move or users can re-authenticate, how many applications need new client settings, how much Lambda trigger logic must be rebuilt, the number of environments to validate, and how much change control and testing your organization requires. Ask for a timeline that separates discovery, build, migration rehearsal, cutover and the period where both systems run in parallel.
What does the migration need from our side?
Plan for time from your identity owners, application owners and security reviewers. You will need to decide which attributes and groups must survive, which applications keep their current token claims, and how users will be told about any password reset or new sign-in step. You will also need access to the AWS account to export users and read pool configuration, a target environment in your own datacenter or cloud account, and a test plan that covers every application. Ask the implementation partner to list these inputs in the written scope so that dependencies are visible before work starts.
Can Cognito password hashes move to the new platform?
Usually not as a direct export. Cognito does not provide password hashes in its user export, so you cannot simply copy them into Keycloak, ZITADEL or Ory. The two practical approaches are forcing a password reset for every user, or migrating each user at sign-in, where the new platform verifies the password against Cognito once and then stores the new credential. Each approach affects user experience, help desk load and how long the old pool must remain available. Confirm the approach for your user population with the target platform's migration documentation and your security team before you commit to a cutover date.
How do AGPL and enterprise licensing affect shipping identity inside our product?
Licensing depends on how you distribute the software, not only on whether you use it. Keycloak is licensed under Apache License 2.0. ZITADEL's core, Console and hosted login moved from Apache 2.0 to AGPL-3.0 with v3.0, while its APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. The AGPL can require source availability for modified network-facing code, so product teams that bundle ZITADEL must review that obligation with counsel. authentik's core is MIT, but its enterprise directory uses a separate license. Ory's open-source components are Apache-2.0, while its enterprise features come under the Ory Enterprise License. Have legal confirm the exact license of each component you plan to bundle.
Does DeployOpen handle the whole move, or only part of it?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide. DeployOpen does not publish a price list, so ask for a quote based on your written scope.
How DeployOpen approaches this
We start by fixing the deployment constraints before choosing between Keycloak, ZITADEL and Ory. The decisive questions are where the product must run, which Regions or data centers hold user records, whether customers bring their own identity providers, and how many separate deployments must present the same login. Our written scope records each of these answers, along with the protocols the product's applications and partners already use, such as OpenID Connect, OAuth 2.0 or SAML 2.0. A platform choice made before those answers exists tends to be revisited during rollout, so we treat the scope document as the first deliverable.
Next we test the riskiest assumption in the design: whether one login can span every deployment. That means proving the chosen platform's high availability model, database requirements and upgrade path inside the client's own infrastructure, including how the database is backed up and how schema changes are applied. For Keycloak, this means checking the export and import limits described in its documentation and choosing a realm strategy that keeps the token issuer and the sub claim stable. Ask the candidate platform's vendor or community to confirm each point against the version you intend to run, because release cadences and supported database versions change.
Finally, we shape the handover so the client's team can operate what was built. Deliverables typically include the deployment configuration, documented client and realm mappings, a tested sign-in path for each deployment, and evidence for the controls the client's assessors will ask about. Support and upgrades can be agreed as a retainer after the initial rollout, so the scope of ongoing work is clear before go-live. We do not issue audit reports or certifications; independent assessors do that work, and we prepare the systems and records they review.
