Self-hosted Doppler alternative for EU data residency

Why Doppler's cloud does not meet an EU-only hosting rule

If an EU-only hosting or data residency rule applies to your secrets, Doppler's standard cloud does not meet it, because the service runs its servers in Google Cloud us-central1, in the United States. Secrets such as database credentials, API keys and signing material are personal data only in some cases, but they are often the keys to systems that hold it, so a rule that covers the data store usually covers them too. Confirm with your data protection officer and legal team whether the rule applies to secrets, and which transfers it treats as in scope, before you choose a replacement. Doppler's Enterprise Key Management does not close the gap. In that model the customer-controlled key lives in the customer's own AWS or GCP KMS, but the sealed secrets data still resides on Doppler's infrastructure. Ask Doppler in writing where the sealed data, backups, logs and support access sit, and whether any of them are reachable from outside the EU. The answer determines whether this option can satisfy your rule at all.

The short answer is one of three paths. Doppler On-prem, offered with an Enterprise plan, is designed to keep secrets, backups and access patterns inside your environment, so confirm its deployment location and the EU boundary in the contract. Infisical Cloud's EU region, served at the eu.infisical.com API endpoint, keeps the hosted service in an EU region, but you still need to verify where backups, logs and vendor support access are located. Self-hosted Infisical or self-hosted OpenBao puts the whole stack in infrastructure you choose, in an EU data center or EU cloud region you control, which gives you the most direct evidence for a residency assessment. The rest of this page compares these options.

What an EU-only rule requires of a secrets manager

An EU-only hosting rule is usually a transfer question under the GDPR, not just a question of which data center holds the bytes. The cards below set out the requirements a controller should assess before choosing where secrets live, since secrets often contain personal data or access to systems that hold it.

Transfers are a Chapter V question

Article 44 requires that every transfer of personal data to a third country, including onward transfers, meets the conditions in Chapter V. Secrets that embed personal data, service credentials for systems holding personal data, or audit logs about people all fall within scope. Ask your DPO whether the secret store itself is a processing activity and where each copy, backup and log of it is held. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover.

Remote access counts as transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. An vendor's support engineers or follow-the-sun administrators outside the EEA can therefore create a transfer even if the servers stay in Europe. Check who can open the console, read a secret in the vendor's tooling, or take a support session, and from which countries.

Key location is not data location

A customer-held key does not settle the question if the encrypted secrets still sit with the vendor. The EDPB Recommendations 01/2020 state that where a provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask where ciphertext, backups and metadata reside, and who can decrypt them when the vendor is compelled to act.

Schrems II and the Data Privacy Framework

In Case C-311/18 (Schrems II), the CJEU invalidated the Privacy Shield on 16 July 2020 while upholding standard contractual clauses. 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. A vendor's US certification therefore needs ongoing monitoring rather than a one-time check. Record which transfer tool you rely on and when you last reviewed it.

Third-country law reaches the vendor

The US CLOUD Act, at 18 U.S.C. 2713, requires providers to preserve or disclose data in their possession, custody or control, wherever it is located. GDPR Article 48 limits recognition of a foreign disclosure order to cases based on an international agreement such as a mutual legal assistance treaty. Ask a vendor how it responds to such requests, whether it commits to challenge them, and whether it can show it holds no key or data that would make a compelled disclosure possible.

How each option meets or misses the constraint

Doppler's standard cloud runs its service in Google Cloud us-central1, a United States region, so an EU-only hosting rule is not met by the default deployment. Enterprise Key Management lets you hold the encryption key in your own AWS or GCP KMS, which strengthens control over the key. It does not move the data. Doppler's documentation states that the sealed secrets data still resides on Doppler's infrastructure, so the ciphertext, and the service that serves it, remain outside your control.

Data location: Secrets are stored on Doppler's infrastructure, which the platform documentation places in us-central1.
Key control: The customer-controlled key lives in the customer's AWS or GCP KMS, which is a separate question from where the data sits.
Access path: Support and operational access by Doppler staff and subprocessors are transfers to assess under the EDPB guidance on remote access.
Legal exposure: A US provider can be subject to the CLOUD Act, so a third-country disclosure request is a risk to assess even with an EU processor arrangement.
Contract terms: Ask for written commitments on region, subprocessors and data return or deletion.

Confirm with Doppler in writing whether any EU region is offered for your plan and which subprocessors touch the data.",

Which open-source option fits which EU residency setup

This table compares self-hosted Infisical, self-hosted OpenBao and the Infisical EU cloud against an EU-only hosting rule, along with licensing, enterprise features and operating effort. Read each row against your own residency and licensing requirements, since the answer depends on where your team will run the servers and who operates them.

Requirement	Self-hosted Infisical	Self-hosted OpenBao
Where secrets are stored	Inside your own EU cloud account, data center or network that you choose	Inside your own EU cloud account, data center or network that you choose
Infisical EU cloud option	Infisical Cloud has an EU region served at eu.infisical.com, so confirm with Infisical whether its EU region meets your contract and transfer terms	Not applicable, since OpenBao is not offered as a vendor-hosted service by the project
License for the core product	MIT Expat for the repository, except content in ee directories, which is under the separate license in ee/LICENSE	MPL-2.0, with the project governed under OpenSSF and the Linux Foundation
SSO and enterprise features	SSO and gateways require enterprise licensing, so confirm the license cost and terms before you design around them	Login MFA and auth methods such as OIDC, LDAP and Kubernetes are documented in the open-source project
High availability storage	Relies on the PostgreSQL and Redis components in the official Helm chart, so you own their HA design	Integrated Raft storage or PostgreSQL with an active node and standbys, which you must size and monitor
Unsealing and key custody	Managed through the application and its database, so review how encryption keys are protected in your environment	Shamir unseal keys are your responsibility, so define a documented unseal and key ceremony before go-live
Operating effort	Lower for teams that want a dashboard, syncs and a Kubernetes operator out of the box	Higher, since you run cluster storage, unsealing, upgrades and backups yourself

How to deploy Infisical or OpenBao inside an EU boundary

This sequence moves secrets out of a Doppler SaaS tenant into a self-hosted platform whose hosting region, data flows and access paths are fixed and documented before any production secret is copied.

Confirm the hosting region and data flows
The compliance owner and the platform team list every place secret data could sit or pass through: the primary cluster, backups, logs, monitoring, support access and any syncs to external platforms. Each location is mapped to an EU Member State or another jurisdiction you have assessed. Ask Doppler in writing where its sealed secrets are stored under your current plan, and confirm the answer against the Enterprise Key Management documentation. The step is done when the data flow diagram and the location list are signed off by the data protection officer.
Choose the deployment method and platform
The team picks either self-hosted Infisical or OpenBao based on the team model and operational skills. Infisical offers a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments. OpenBao is installed with its Helm chart, which requires Helm 3.6 or later, or on virtual machines, with integrated Raft or PostgreSQL as its high availability storage. Confirm whether the features you need, such as SSO or gateways, need an Infisical enterprise license. The step is done when the target architecture is written down and the vendor licensing question is answered.
Build the EU hosting environment
The platform team provisions compute, storage, database and network resources inside the chosen EU region or your own data center, with private endpoints where possible. Storage encryption keys, TLS certificates and the unseal or key material are placed under your control and stored separately from the application data. If you use an EU-hosted managed database for Infisical, confirm its region and its provider's support access model. The step is done when a test instance starts, serves health checks and stores data only in the approved location.
Configure high availability, backups and auth methods
The team sets up highly available storage, such as the Raft or PostgreSQL backends OpenBao supports, or the PostgreSQL and Redis components in the Infisical chart, and writes a tested backup and restore runbook. Machine identities are then configured with the methods your workloads need, such as Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth for Infisical, and AppRole for servers and Userpass for developer machines for OpenBao. Access roles and approval workflows are defined before any secret is loaded. The step is done when a restore has been rehearsed in a separate environment and each workload class has a working identity.
Migrate secrets from Doppler
For Infisical, the team uses the documented Doppler importer with a service account token and imports one environment at a time into the chosen folders. For OpenBao, which has no Doppler importer, the team exports each Doppler config as JSON with the CLI, writes it to KV paths, and maps projects to mounts and policies. Imported values are checked against the source for a sample of keys, and export files are deleted from workstations after use. The step is done when every config has a matching target path and the owners have confirmed their secrets.
Cut over syncs and workloads
Each workload and CI pipeline is switched from Doppler to the new platform one group at a time, with the previous Doppler credentials kept available for rollback. Doppler syncs to external platforms are replaced by equivalent Infisical syncs or by workload identities that read directly from OpenBao. Dynamic secrets are reissued from the new platform, and the old Doppler tokens are revoked once the group is stable. The step is done when no production workload reads from Doppler and the revocation is recorded in the change log.
Document the transfer position and retire Doppler
Counsel and the compliance lead record the final data flow, the remaining third-country exposure, if any, and the contractual terms with each remaining processor, including support access. Doppler is asked to confirm deletion of the tenant data in writing, and the retained evidence is filed. The team also records the Infisical or OpenBao version in use and the upgrade route for later releases. Independent auditors and regulators, not DeployOpen, decide whether the arrangement satisfies a specific legal requirement. The step is done when the transfer assessment is signed and the deletion confirmation is on file.

What changes for your teams during the move

Doppler's hierarchy of project, environment and config is the first thing to map before any secret moves. In Infisical, a Doppler project maps to an Infisical project, Doppler environments map to Infisical environments, and Doppler branch configs map to folders inside those environments, so teams can keep a model they already know. Infisical documents a Doppler import that pulls root and branch configs into environments and folders you choose, one environment at a time, which lets you review the mapping before cutover. OpenBao has no Doppler importer, so the mapping is a design task: you decide the KV mount layout, typically one mount or path prefix per project and one path segment per environment, and then write policies that grant each workload read access only to its own path. Confirm the import behavior against the current Infisical documentation in your own test environment before you rely on it.

The move also changes how workloads authenticate and how secrets reach them. Doppler service tokens are replaced by machine identities in Infisical, which can authenticate with Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, with access governed by roles and approval workflows. In OpenBao, the auth method choice follows the workload: the documentation recommends Userpass for developer machines and AppRole for servers. Doppler syncs to platforms such as GitHub or Vercel need an explicit replacement, either a native Infisical sync or a pipeline step that reads from OpenBao. Dynamic secrets and any rotation schedules must be rebuilt by hand in both cases, and each replacement should be tested in a non-production environment before production traffic moves over.

Evidence to collect for an EU residency review

A residency review is decided by records, not by vendor claims. The five items below are the evidence a CISO or privacy lead should be able to produce for any secrets store, whether it stays with Doppler, moves to Infisical's EU cloud or runs self-hosted, and DeployOpen prepares this evidence but does not issue audit reports or certifications.

Data location records

Record where every secret store, replica, log sink and key lives, by provider, region and country. For Doppler, the relevant question is where the sealed secrets sit, since its Enterprise Key Management documentation says the customer-controlled key sits in the customer's own AWS or GCP KMS while the sealed secrets data still resides on Doppler's infrastructure. Ask the vendor to name the region in writing, and for self-hosted options, record the exact data center or cloud region you choose.

Transfer impact assessment inputs

Collect the facts a transfer impact assessment needs: which entities can access data in the clear, under which third-country laws, and whether support staff abroad can view secrets on screen. EDPB Guidelines 05/2021 treat remote display from a third country as a transfer, so support access counts. Document the outcome of each assessment and the supplementary measures you chose, and do not assume an EU processor removes the exposure.

Access logs and role configuration

Export the role assignments for every project, environment and secret path, along with the logs that show who read or changed a secret and from where. Compare these with the staff who are allowed to see production values. For self-hosted Infisical or OpenBao, confirm that logs are written to a store you control, and that the policy files or RBAC roles can be exported on request.

Backup location and retention settings

Backups often leave the primary region without anyone noticing. List every backup target, its region, encryption key owner, retention period and restore test date. Ask the vendor whether backups of sealed secrets are kept outside the chosen region and for how long. In a self-hosted deployment, these are settings you define in your own storage, so write them into the runbook and verify them in a restore exercise.

Vendor and processor terms

Gather the data processing agreement, sub-processor list, notice of changes to sub-processors and the contractual clauses that cover any transfer. Confirm which law governs the processor and whether it has received government access requests. For a self-hosted option, the main processor relationship may be with an implementation partner, so the scope of work, data handling and exit terms should be recorded in writing before work starts.

Questions buyers ask before hiring help

What drives the cost of self-hosting Infisical or OpenBao instead of Doppler?

Cost depends on who pays for which component, and on how much of it recurs. Doppler's cost is mainly per-seat subscription fees plus any add-ons, and it recurs every term. Self-hosting shifts that spend to infrastructure, storage and staff time. The main components are the servers or cluster capacity in your own cloud account or data center, a PostgreSQL database (Infisical also uses Redis in its Helm chart; OpenBao can use integrated Raft storage or PostgreSQL), backups, monitoring, upgrades, and the engineering hours to run it. One-time costs include the initial deployment, migration of secrets and integration work. Recurring costs include infrastructure, support retainers and upgrade effort. Costs rise with the number of environments, HA requirements and the volume of syncs. Ask any implementation partner for a quote that separates one-time work from recurring support, and state which Infisical features, such as SSO, would need an enterprise license.

How long does a migration off Doppler take, and what changes the timeline?

The duration depends on the number of projects, environments, configs and integrations, not on a single fixed period. The fastest path for Infisical is its documented Doppler import, which pulls configs one environment at a time. OpenBao has no Doppler importer, so it requires exporting each config and rebuilding mounts, policies and dynamic secrets by hand. Other drivers include how many syncs to GitHub, Vercel, AWS or Kubernetes must be replaced, whether dynamic database credentials are in use, the compliance evidence you need to collect, and how many teams must test their workloads. Your EU hosting design, including region, network paths and backup location, also affects the schedule. Under the EU Data Act, a switching right exists with a maximum two-month notice period and a 30-day transition, which can set a contractual boundary. Ask for a written scope with milestones before work begins.

What does our team need to supply for a self-hosted secrets migration?

Your team needs to supply the inventory and decisions that only you can make. Expect to provide a list of Doppler projects, environments and configs, the workloads and CI pipelines that read them, and the owners of each. You also need a cloud or data center environment with network, DNS, certificate and backup capacity that meets your residency rule, and identity sources such as your SSO provider and Kubernetes or cloud IAM. Security and compliance staff should define access roles, approval rules and evidence requirements. Someone must have authority to approve a cutover window and rollback plan. Confirm with the vendor which Doppler export formats and service account permissions you will use, and confirm the Infisical or OpenBao version you intend to deploy against the current release notes before scoping.

Can our own platform team deploy Infisical without outside help?

Yes, many platform teams can deploy Infisical themselves, provided they have container, database and Kubernetes skills. Infisical's self-hosting documentation lists several routes: a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments. A pilot in a non-production environment is a sensible first step. The harder work is production operation: high availability, backups and restore tests, certificate management, upgrades, monitoring and incident response. Teams that lack these skills, or that must demonstrate controls to an auditor, often bring in outside help for design, hardening and documentation. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and offers retainers for ongoing support.

Do we need an Infisical enterprise license to use SSO when self-hosting?

Yes, according to Infisical's self-hosting documentation, enterprise features such as SSO and gateways require enterprise licensing. The core project is MIT Expat licensed, but content in any ee directory falls under the separate license in ee/LICENSE, so you should read that file with your legal team before deploying. Confirm the exact feature list, the license terms and whether the license is per instance or per seat directly with Infisical before you make an architecture decision. If SSO is a hard requirement and an enterprise license is not in your budget, compare OpenBao, which documents auth methods including OIDC, LDAP and Kerberos, and which is MPL 2.0 licensed.

Does self-hosting remove all third-country exposure for our EU secrets?

No. Self-hosting in an EU-only environment removes the cloud provider's storage of your secrets outside the EEA, but it does not automatically remove every exposure. Under EDPB Guidelines 05/2021, remote access from a third country, even only displaying data for support, is a transfer, so vendor support sessions, telemetry, software updates, and any managed services you buy must be checked. The EDPB also notes that a third-country authority request for data is itself a transfer, so you should assess the legal reach of every provider that touches your environment, including your cloud provider and any support partner. The US CLOUD Act at 18 U.S.C. 2713 can reach data in a provider's possession, custody or control. Document your data flows, restrict remote access, and have counsel review your transfer assessment. This is a question for your compliance and legal teams, not a guarantee that a platform or partner can provide.

How DeployOpen deploys secrets managers under EU residency rules

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source secrets platforms inside your own cloud accounts, data centers or air-gapped networks. For EU data residency, we start by confirming where every secret, backup and access log must physically sit, then build the deployment to keep them there.

How we scope

We map which secrets, environments, backups and administrator access paths fall under your EU-only hosting rule.
We confirm whether a self-hosted Infisical or OpenBao deployment fits your identity, Kubernetes and CI/CD estate.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.

How we build

We install the chosen platform in EU infrastructure you control, with storage, backups and logging held in the same region.
We configure authentication, access policies and machine identities, and remove any dependency on servers outside the EU.
We test access control, failover and secret rotation in your environment before anything moves into production.

How we hand over

We document the architecture, data flows, data locations, administrator procedures and the recovery steps for your team.
We prepare configuration records and evidence that your compliance lead or independent auditor can review.
We confirm with you which licensing terms and enterprise features apply, such as SSO, before handover is accepted.

How we support

Ongoing support, upgrades, backups and continuous security testing are available as a retainer after handover.
We track platform releases and security fixes, then plan and test upgrades in your own environment.
Retainers can cover changes to data flows, so new integrations keep your EU residency position documented.