Self-hosted Clerk alternative for EU data residency

Why a self-hosted Clerk alternative for EU data residency starts with transfer rules

A European product team that must keep customer login data inside the EU cannot treat Clerk as a residency option. Clerk does not offer regional data residency and hosts its data in the United States, so every login record it stores is in scope for the transfer analysis that GDPR requires. Under Article 44, every transfer of personal data to a third country, including onward transfers, must meet the conditions in Chapter V. Storage in a cloud outside the EEA counts as a transfer, and so does remote access from a third country, even if a support engineer only views data on a screen, according to the EDPB's Guidelines 05/2021. Infringements of Articles 44 to 49 can carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).

The transfer question does not end with the contract. The EU-US Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Standard contractual clauses remain available after Schrems II, but the EDPB's Recommendations 01/2020 say that where a provider's government powers go beyond what is necessary and proportionate, no effective technical supplementary measure may exist. The US CLOUD Act, under 18 U.S.C. 2713, also reaches data in a provider's control wherever it is located. Your legal and privacy team should document this exposure for any US-hosted identity provider before the next renewal.

The short answer is to run an identity provider you control inside an EU datacenter, such as self-hosted ZITADEL, Keycloak or Ory, on infrastructure your organization or a contracted EU provider operates. This moves the storage location of login data, but it does not by itself make the deployment compliant. You still need to confirm the datacenter and backup locations, who holds administrative access, where logs and support tickets go, and whether any component sends data to a US service such as an email or SMS provider. Decide these points in writing before choosing a platform, because they determine what your customer contracts and records of processing must say.

What GDPR and customer contracts ask of identity hosting

Identity data is personal data, so every decision about where Clerk-style user records live is a transfer question under GDPR. The cards below cover the transfer rules, the enforcement exposure, the foreign disclosure risk and the contract terms customers tend to ask for.

Every third-country transfer is covered

Article 44 applies Chapter V to every transfer of personal data to a third country, including onward transfers. The EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when staff only view data on a screen for support, and treat storage in a cloud outside the EEA as a transfer too. For identity hosting, check who can open the user database from outside the EU, including vendor support staff, and where backups and logs are kept. Confirm the scope of each transfer with counsel before choosing a host.

Fines up to 4% of turnover

Infringements of Articles 44 to 49 fall under the higher fine tier in Article 83(5)(c), with fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. A login provider that stores credentials or profile data outside the EU without a valid transfer mechanism creates exposure for the controller, not only for the vendor. Ask your data protection officer to record the transfer mechanism for each system that holds customer identities.

Extraterritorial law and authority requests

The EDPB notes that using an EU processor subject to third-country law with extraterritorial effect is not in itself a transfer. Complying with a request from a third-country authority would be one, though, so controllers should assess that exposure before engaging such a processor. The US CLOUD Act requires providers to preserve or disclose data in their possession, custody or control wherever it is located. Ask any hosting or support vendor for its policy on government requests and whether it holds keys or data in the clear.

Foreign disclosure orders need a treaty

Article 48 allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. This limits how a foreign order can compel an EU controller or processor to hand over identity records. Ask counsel how this applies to a vendor's corporate structure, parent company and support locations.

Customer contracts for EU storage

Enterprise and public-sector customers often require that their users' data stays in the EU, that the provider names its sub-processors, and that it gives notice before adding new ones. Some also ask for audit rights and deletion on exit. These terms sit in data processing agreements, and their exact wording is for counsel to confirm against the customer's own requirements. Use your self-hosted deployment to show where each data store sits, which vendors touch it and how you would exit.

Where Clerk meets these requirements and where it does not

Clerk does not offer regional data residency, and its data is hosted in the US, so EU customer identity data stored there is a transfer to a third country. Under EDPB Guidelines 05/2021, storage in a cloud outside the EEA is a transfer, and Article 44 of the GDPR requires that transfer to meet Chapter V conditions, including onward transfers. Clerk's US hosting is therefore the starting point of the assessment, not a detail to set aside. Ask Clerk in writing where each category of user data is stored, where backups and logs sit, and whether any support or administrative access is possible from outside the EEA, since the same guidelines treat remote access from a third country as a transfer too.

The Data Privacy Framework is a possible basis only where the importer is a US organization on the Data Privacy Framework List, as set out in Commission Implementing Decision (EU) 2023/1795. That decision is under appeal in Case C-703/25 P, so a company should not treat it as settled for a multi-year identity contract. The older route, EU-US Privacy Shield, was invalidated by the CJEU in Case C-311/18 (*Schrems II*), which upheld standard contractual clauses but required an assessment of the destination's law. The CLOUD Act provision at 18 U.S.C. 2713 requires US providers to preserve or disclose data in their possession, custody or control wherever it is located, so a US-controlled processor remains exposed even with EU storage unless the data is protected by technical measures the provider cannot override.

Confirm three things directly with Clerk before relying on its US hosting: the current data processing agreement and the standard contractual clauses it incorporates, the current sub-processor list with locations, and how Clerk responds to government disclosure requests. Clerk's contract terms can change, so the answers must come from the version you sign, not from this page. If the answers do not satisfy your transfer assessment, the remaining options are self-hosting an EU-operated identity platform in an EU datacenter or in your own cloud account, such as ZITADEL, Keycloak or Ory, where the operator, the storage and the keys sit inside your control.

Which self-hosted options keep identity data in the EU

This table compares ZITADEL, Keycloak and Ory on how each fits an EU residency requirement, including where it can run, which database it needs, how tenants are isolated and what the license or operating model adds. Read it as a set of questions to verify in your own environment, because residency depends on where you deploy and who operates the stack as much as on the software itself.

Requirement	ZITADEL	Keycloak	Ory
Deployment location	Self-hosted on Linux or Kubernetes in your EU cloud account or datacenter, with Docker Compose or the official Helm chart	Runs on your EU infrastructure, typically on Kubernetes with the Keycloak Operator installed through Operator Lifecycle Manager	Self-hosted components can run in your EU infrastructure, but confirm the deployment options your edition supports
Supported database	PostgreSQL versions 14 through 18, hosted in the same EU region as the identity service	PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle, Aurora PostgreSQL or Azure SQL, all placed in your EU region	Relational storage backed by PostgreSQL or other supported databases; confirm the current list with Ory
High availability and data placement	Kubernetes with the official Helm chart is the documented route to high availability; keep replicas and backups in EU regions	Single cluster across EU availability zones, or multi-cluster designs that require a synchronously replicated database	Scaling and replication depend on your deployment; confirm how replicas and backups are placed
Tenant isolation	Instances give full data isolation, with organizations and projects nested inside for customer-level separation	Realms isolate users, clients and configuration; separate realms or deployments per regulated customer are common choices	Multi-tenancy depends on how you model identity schemas and projects; confirm isolation options for your edition
Federation of customer identity providers	Each customer organization can use a different OIDC, SAML, LDAP or Entra ID identity provider	Identity brokering and user federation with LDAP and Active Directory, configured per realm	Federation of external providers is available; confirm which SAML and organization features need the enterprise license
Protocol coverage	OpenID Connect, OAuth 2.0, SAML 2.0, SCIM 2.0 and LDAP, with a device authorization grant	OpenID Connect, OAuth 2.0 and SAML 2.0, with SCIM available through extensions	OAuth2 and OIDC through Hydra; confirm SAML and SCIM support against the current license
License	AGPL-3.0 for the core, with Apache 2.0 for APIs, SDKs and Helm charts; confirm how AGPL terms apply to your modifications	Apache 2.0, with a Cloud Native Computing Foundation incubating project status	Open-source core with an enterprise license for some features; confirm the exact terms with Ory before planning
Operating trade-off	Go services on PostgreSQL; your team runs upgrades, backups and monitoring for the EU stack	Java runtime operations, cluster tuning and database schema upgrades; a mature community with a large operator base	Several separate services to deploy and monitor; suits teams building their own login screens

How to deploy identity in an EU datacenter under this constraint

This sequence takes an EU product from a transfer map and operator review through a PostgreSQL-backed ZITADEL or Keycloak deployment, user migration and an EU-only check of logs, metrics and backups. The result is an identity service whose customer data, operations and recovery copies stay in the EU, with evidence for your assessment.

Scope the data inventory and transfer map
List every identity data element Clerk holds for your users, including profile fields, hashed passwords, passkeys, MFA factors, organization memberships, enterprise connection metadata, session records and support notes. Record where each element is stored today, which staff or vendors can access it, and whether any copy leaves the EEA. Your privacy lead should confirm this map against GDPR Chapter V, because remote viewing from a third country counts as a transfer under EDPB Guidelines 05/2021, not only storage. Done when every element has a named location, an access list and a transfer decision.
Choose the EU region and confirm operator location
Select an EU datacenter or cloud region for the production cluster, the database, the standby site and the backup target, and write them down. Ask any hosting provider, managed database vendor or implementation partner where its administrators and support staff are located and whether they can view data from outside the EU. Ask the provider how it answers third-country authority requests, since EDPB Recommendations 01/2020 treat cloud access to data in the clear as a central risk. Done when you hold a written location map for every system, including people who can reach it.
Deploy ZITADEL or Keycloak on PostgreSQL
Deploy the chosen identity server in the EU region using the official ZITADEL Helm chart or the Keycloak Operator on Kubernetes, backed by PostgreSQL. Supported PostgreSQL versions are 14 through 18 for both ZITADEL and Keycloak. For high availability, use a database with synchronous replication, because Keycloak's supported multi-cluster designs require it. Done when the cluster passes a login test from a client in the EU and the database failover test confirms that no committed identity records are lost.
Lock operator and server updates to manual approval
Set the Keycloak Operator to manual approval mode so that upgrades do not start automatically, which the Operator documentation strongly recommends. Pin the chart or image version, and schedule each upgrade with a tested rollback plan. Keycloak runs automatic schema migration at startup by default, so decide whether your team applies migration SQL manually, which the upgrading guide suggests for large deployments. Done when the update policy is written into your change procedure and a staging upgrade has been rehearsed.
Plan export limits and backups with nodes stopped
Treat Keycloak realm export and import as a migration tool rather than a backup method, because the documentation lists limitations and requires all nodes to be stopped during the process. Use database-level backups on PostgreSQL for recovery, and store encrypted copies only in EU locations. Test a full restore into a separate EU environment and record the time it takes. Done when a restore has been verified and the runbook names the people allowed to start it.
Migrate users with just-in-time or import
Export users from Clerk with their password hashes, following the Clerk export guidance, and check that the file is complete before any import. Choose between a bulk import that keeps passwords, which requires the hash format to be supported by the target, and just-in-time migration, where ZITADEL's migration guides describe a flow that moves each account on first login. Map Clerk organizations to ZITADEL organizations or Keycloak realms and groups, and confirm that enterprise connections are rebuilt inside the EU. Done when a sample of accounts logs in on the new system and the migration log shows no unmatched records.
Verify that logs, metrics and backups stay in the EU
Trace every telemetry and recovery path: application and audit logs, Keycloak or ZITADEL metrics, error tracking, alerting, container registries, and backup copies. Confirm that each destination is in the EU and that no sink, SaaS dashboard or support tool receives personal data outside it. Check whether logs contain identifiers such as email addresses and reduce them where possible. Done when a dated register lists each data path, its location, and the evidence an independent auditor would ask to see.

Questions buyers ask before hiring help for EU identity hosting

How much effort does a single-region EU identity deployment take?

Effort depends mostly on how many applications, identity sources and customer tenants sit behind the identity provider, and on how much of the login experience must be rebuilt. A single-region deployment in an EU datacenter is less work than a multi-region design, because it avoids cross-region replication and failover testing. The main drivers are the number of identity sources to federate (LDAP, Active Directory, Entra ID, Okta or others), whether customers need their own enterprise SSO connections, the number of login flows that need custom theming, and the target availability design. Keycloak documents a high availability architecture that needs a synchronously replicated database, and ZITADEL recommends Kubernetes with the official Helm chart for high availability, so the platform choice shapes the work. Ask for a written list of applications, identity sources and login flows before any estimate.

Can an in-house team run a self-hosted EU identity platform?

Yes, many teams can, provided they have people who already operate Kubernetes or Linux services, PostgreSQL, backups and certificate management. The work is not only the first deployment. Someone must own upgrades, monitoring, incident response, user lifecycle issues and security patches on a continuing basis. Keycloak now ships four minor releases a year, and its Operator documentation recommends manual approval mode for updates, so an upgrade calendar and a test environment are needed. The questions to answer honestly are whether the team can staff an on-call rotation, whether it can test an upgrade before production, and whether it has security review capacity for changes to login flows. If any of these are thin, a fixed-scope implementation followed by a retainer for upgrades and support is a common pattern.

How long does an identity migration take, and what sets the timeline?

The timeline depends on scope, and no single duration applies across products. The largest variables are the number of user records, whether password hashes can be exported and imported so users keep their passwords, how many customer organizations and enterprise connections must be recreated, and how many applications must switch their login integration. The source platform matters too. Auth0 does not include password hashes in standard exports and requires a support request for paid plans, so that step can add lead time. Migration plans usually include a parallel run, a cutover window and a rollback path. Ask for a written plan with phases, the systems in each phase and the decision points where your team signs off before any date is committed.

What does the client need to provide for an EU identity engagement?

Clients usually provide the infrastructure and access that the work depends on. The list typically includes an EU cloud account or datacenter allocation, DNS control for the login domains, TLS certificates or a certificate process, access to the existing identity provider for configuration and user export, and named contacts for application owners. Sign-off on data flows is equally important. Before deployment, the client should confirm where user records, logs, backups and support access sit, and which third parties can reach them. Under GDPR, the EDPB treats remote access from a third country as a transfer, so support access needs to be defined in the scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification.

How do recurring identity hosting costs split across infrastructure, database, staff and upgrades?

Recurring cost comes from four components: infrastructure, the database, people and upgrades. Infrastructure covers compute for the identity servers, load balancers, storage, backups and, for high availability, extra nodes across availability zones. The database is usually PostgreSQL, and Keycloak and ZITADEL both document supported versions, so a managed or self-operated database has its own licensing or support cost and replication needs. People cover on-call operations, security patching and user support, and this is often the largest line. Upgrades recur at each minor or major release and need a test environment and change review. Ask for a quote that shows each component separately, with the assumptions for user volume, availability target and support hours, so you can change one input and see the effect.

Is a fixed-scope engagement available, with ongoing retainers after go-live?

Most DeployOpen engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. A typical split is a fixed-scope project to plan, implement, integrate, harden, back up and document the platform, followed by a retainer that covers upgrade windows, monitoring follow-up, security testing and changes to login flows. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the deliverables list, the acceptance criteria, what is excluded, and how change requests are priced before signing. If your team wants to keep operating the platform alone, ask for a handover plan and runbooks as part of the scope.

Evidence assessors and regulators ask for

A data residency claim is only as strong as the records behind it. The cards below cover the artifacts that assessors and data protection authorities typically request when identity data stays in the EU. DeployOpen prepares this evidence, but auditors and regulators make the final determination.

Data flow and transfer map

A diagram and table showing where each identity record is created, stored, backed up and viewed, including logs, email delivery and support access. The map should show no storage or remote access from a third country at any step. Check the map against the EDPB's view that displaying data on a screen from outside the EEA can count as a transfer, and include administrator sessions and vendor support paths in the review.

Processor and sub-processor list

A register of every processor and sub-processor that touches the identity service, with the legal entity, the country of processing and the service it provides. For each one, confirm whether it can access data in the clear and whether it is subject to third-country law with extraterritorial reach. Ask each provider for written confirmation of its hosting locations and for its government access request policy.

Configuration and access records

Infrastructure-as-code, container image versions, database settings, TLS configuration and the list of people who hold administrator, database or cloud console access. Keep change records for the identity platform itself, including who approved each upgrade. For Keycloak, the operator update mode and the database migration method are part of this record, so document which was chosen and why.

Backup and restore tests within the EU

Evidence that backups of the identity database are stored in EU locations and that restores have been tested in the same region. Keycloak's export and import of realms has documented limits as a backup method and requires all nodes to be stopped while it runs, so the restore test should use a method the team has validated. Record the date, scope and result of each test, and where the restored data was held.

Transfer impact assessment and contract terms

The contract with each vendor, the standard contractual clauses where any transfer remains, and a transfer impact assessment that addresses third-country government access. Ask counsel to review whether the Data Privacy Framework applies to any vendor, since its adequacy finding covers only US organizations on the list. Confirm the vendor's position on requests under the US CLOUD Act before relying on an EU-only deployment.

How Data Act switching rights support a move back to EU hosting

The EU Data Act gives customers of data processing services a legal route out of a provider, and that route matters if your identity data currently sits with a US-hosted service such as Clerk. The Data Act has applied since 12 September 2025. It gives customers the right to switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition period (Articles 25, 29 and 50 of Regulation (EU) 2023/2854). From 12 January 2027, providers may no longer charge switching fees. Confirm with your Clerk contract and account team how notice, transition and any data export obligations apply to your plan, and whether your agreement or order form contains terms that go beyond the statutory minimums. The Data Act text on EUR-Lex is the starting point for your legal review.

Article 32 of the same regulation adds a second obligation that bears on this decision. Providers must take technical, organisational and legal measures to prevent third-country governmental access to non-personal data held in the Union where that access would conflict with EU or national law. The Data Act does not settle personal data questions, which remain under GDPR transfer rules, so treat it as one input alongside your transfer analysis. Ask your current provider in writing where identity data is stored and processed, which sub-processors have access, and how they respond to foreign government requests. Then compare the answers with the destination you plan, such as a ZITADEL, Keycloak or Ory deployment in an EU datacenter that you operate under your own control.

How DeployOpen deploys identity in your EU infrastructure

DeployOpen plans, implements, hardens, documents and supports self-hosted identity platforms inside your own cloud accounts, data centers or air-gapped networks. For EU data residency, that means the identity store, backups, logs and admin access stay in the EU regions and facilities you choose, under a fixed scope agreed in writing before work starts.

How we scope

Map which customer identity data, logs and backups must stay in the EU and who can reach them
Agree in writing which platform fits the use case: ZITADEL, Keycloak or Ory
Record the EU hosting location, admin access paths and third-country support exposure
Confirm the migration source, export method and password hash handling before any import

How we build

Deploy on your EU infrastructure with PostgreSQL 14 or later and a tested backup route
Configure SSO connections, SCIM provisioning and identity brokering for your customer organizations
Test login, MFA, passkey recovery and token behavior against the agreed scope
Harden admin consoles, network paths and secrets handling to the written baseline

How we hand over

Deliver architecture, data flow and data location documentation for your records of processing
Provide runbooks for upgrades, backup and restore, and high availability failover
Document the export and restore steps your team will need in an incident
Give evidence of controls for your auditors, noting that independent auditors issue any attestation

How we support

Ongoing support, upgrades and continuous testing are available as retainers
Retainers can cover upgrade planning for each platform's release cycle
Ask any provider for written commitments on support hours, response and locations before signing
Confirm with your legal team how the contract terms treat transfers and processor obligations