Migrate from Doppler to OpenBao

Migrate from Doppler to OpenBao: what the rebuild involves

OpenBao has no Doppler importer, so moving from Doppler to OpenBao is a rebuild, not a transfer. You export each Doppler config, recreate the project and environment structure as OpenBao KV paths, mounts and policies, and then replace the work Doppler did for you: syncs to cloud platforms and CI, and dynamic secrets. This matters most if your renewal, licensing change, residency rule or lock-in concern is pushing you off Doppler and you need a clear end state before the contract ends. Start by inventorying every config, sync, integration and service token, because each one needs a named replacement in OpenBao before Doppler is switched off.

The work usually falls to a platform or security engineering team, with the application owners who consume each config involved in cutover testing. The export itself is the easy part. The doppler secrets download --no-file --format=json command writes one config as JSON to standard output, and Doppler's documentation recommends process substitution so values never touch disk. The harder parts are deciding how projects map to mounts and policies, rewriting application and pipeline reads, and recreating each sync as a client, template or agent pull. Dynamic secrets need a separate decision, because Doppler issues them only when include_dynamic_secrets is set and their leases expire after 1,800 seconds by default, so the OpenBao database or Kubernetes engine must be configured from scratch.

Effort and risk depend on how many configs, syncs and dynamic secret sources you have, and on how much of the OpenBao platform, including HA storage, unsealing, backups and upgrades, you run yourself. Ask any implementation partner to confirm these in writing: the inventory, the mapping decisions, the cutover and rollback plan per config, and who holds unseal material. DeployOpen plans and implements this kind of rebuild under a fixed scope agreed in writing before work starts, and the quote follows from that scope. Confirm the OpenBao release you will deploy against the OpenBao releases page before scoping, because the platform changes between minor lines.

Which Doppler capabilities map cleanly to OpenBao

This table maps each Doppler capability to its closest OpenBao equivalent and marks it as clean, needs rework or gap. Use it to scope the rebuild before exporting any config, since the rows marked as gaps or rework set most of the migration effort. Read the rows for syncs and integrations first, because they have no direct equivalent in OpenBao.

Doppler capability	OpenBao equivalent	Status
Projects and environments	KV v2 mounts or paths per project and environment, with one policy per team or workload	Needs rework: the hierarchy is a naming convention you define, not a built-in object
Configs (for example dev, stg, prd)	One KV v2 path per config under a shared mount, such as a secret/app/config path pattern	Needs rework: keep config names identical to Doppler so exported JSON maps one to one
Secret values and versions	KV v2 secrets with version history, written with bao kv put from a JSON file	Clean: a single write per config is the core rebuild step
Service tokens	Tokens issued by AppRole for servers, or Kubernetes and JWT/OIDC auth for workloads	Needs rework: each token must be replaced by a role with a narrow policy
Access control by project and environment	Path-based ACL policies attached to auth roles	Needs rework: Doppler roles do not translate, so write policies from scratch
Developer access to secrets	Userpass for developer machines, with login MFA where your standard requires it	Clean: OpenBao recommends Userpass for developer machines
Secret syncs to cloud platforms and CI	No direct equivalent: a workload or pipeline must read from OpenBao with its own auth	Gap: each sync must be rebuilt with an agent, operator, or pipeline step
Dynamic secrets	Database and Kubernetes dynamic secret engines with leases and automatic revocation	Needs rework: Doppler's dynamic secrets are not exported, so define new engines and roles
Download API and CLI export	Doppler export produces JSON, which bao kv put reads with the @ file prefix; the OpenBao API replaces runtime reads	Needs rework: the export is clean, but application reads must change to OpenBao calls

What data moves and which integrations must be rebuilt

Doppler's secret values can be exported config by config and written into OpenBao KV paths, but nothing else comes with them. Each card covers one part of the move, from the export command to the consumers and identities that must be recreated by hand before cutover.

Export each config as JSON

Run doppler secrets download --no-file --format=json once per config, for each project and environment you plan to move. The command prints one config's secrets to standard output, so pipe it directly into the next step rather than saving it as a plain-text file. Confirm the exact flags against your installed Doppler CLI version, and record the project, environment and config name for every export so the mapping stays traceable.

Write values with bao kv put

Load each exported JSON into an OpenBao KV path using bao kv put with the @ prefix to read the data from a file, for example bao kv put -mount=secret foo @data.json. Where possible, use process substitution so decrypted values never land on disk. Check that key names survive the round trip, since Doppler config keys with special characters may need a naming decision before import.

Rebuild application runtime access

Applications that currently receive secrets through Doppler's CLI or SDK at startup need a new retrieval path. Choose an OpenBao auth method per workload, such as AppRole for servers, and change each service to read from its KV path with a policy that grants only that path. Test each service in staging before removing its Doppler token.

Replace CI pipeline injection

Build pipelines that pull Doppler secrets into jobs must authenticate to OpenBao instead. Decide how each runner proves its identity, for example through JWT/OIDC from the CI platform, and scope each job to the paths it needs. Rotate any Doppler service tokens still referenced in pipeline variables once the new path works.

Redo Kubernetes workload delivery

Doppler's Kubernetes operator and any sync-based delivery into cluster secrets must be replaced with a method OpenBao supports, such as the OpenBao Helm chart for the server and a Kubernetes auth method for workloads. The OpenBao Helm chart requires Helm 3.6 or later. Confirm which secret-injection component your clusters will use before cutover, because it is a separate build item.

Recreate cloud syncs and identities

Doppler syncs that push secrets into cloud platforms have no OpenBao equivalent, so each target needs a replacement such as a provider integration or a scheduled job. Doppler users, roles and audit history do not transfer. Recreate people and machines as OpenBao identities with policies, and keep the Doppler audit export as a separate evidence record.

Migration sequence from inventory to decommission

This sequence moves Doppler configs into OpenBao one at a time, starting with a non-production pilot and ending with Doppler tokens and syncs revoked. Each step produces a written artifact so the team can see what has moved and what still depends on Doppler.

Inventory projects, environments and configs
Platform or security engineering lists every Doppler project, environment and config, along with the services, CI jobs and cloud syncs that read each one. Use the Doppler dashboard or the CLI to enumerate them, and record which workloads use service tokens and which use dynamic secrets. The output is a mapping sheet with one row per config, its consumers, its owner and its target OpenBao path and policy. Treat the sheet as the working plan, because later steps depend on it being complete.
Pilot one non-production config
Choose one non-production config with few consumers and export it as JSON with the Doppler CLI, using process substitution so values never land on disk. Write it to a KV path in a test OpenBao mount with bao kv put and the @ file prefix, then point one non-critical workload at OpenBao. The pilot is done when the workload reads the values, a rotation in OpenBao reaches it, and the team has documented every manual change it needed.
Define and test policies per mount
Turn the mapping sheet into OpenBao mounts, paths and policies, grouping configs by project and environment so each workload receives only the paths it needs. Choose auth methods per consumer, such as AppRole for servers and Kubernetes or JWT/OIDC for platforms that support them. Test each policy with a token that should be allowed and one that should be denied. The output is a tested policy set with a record of each allowed and denied check.
Run a parallel period with dual reads
For each remaining config, make the consuming application read from OpenBao while Doppler stays live as the source of truth, then compare values during the overlap. Keep Doppler syncs running so a rollback is a configuration change. Track any mismatch, missing key or failed lease in a shared log. The parallel run ends for a config when the comparison is clean and the owning team signs off on the cutover checklist for that config.
Cut over each config
Move one config at a time: freeze changes in Doppler for that config, confirm the latest values exist in OpenBao, switch the workload's configuration to OpenBao, and verify its health checks. Replace any Doppler dynamic secret with an OpenBao dynamic secrets engine and confirm leases expire and revoke as designed. The cutover checklist for each config records the time of switch, the owner, the rollback step and the verification results.
Replace Doppler syncs and dynamic secrets
Doppler syncs push secrets into cloud platforms, CI systems and Kubernetes. For each sync, confirm whether the destination can read from OpenBao directly, through a supported integration, or through a documented pull job, and build that replacement before removing the sync. Re-test each destination after its source changes. The output is a sync inventory showing each old sync, its replacement and its test result.
Decommission Doppler tokens and syncs
After every config has run on OpenBao for an agreed observation period, disable each Doppler sync, revoke service tokens and remove Doppler CLI access from automation and developer machines. Confirm that no workload still authenticates to Doppler by checking access logs. Export a final archive of the Doppler configuration and retain it under your records policy. The sequence is complete when the decommission record shows zero active Doppler tokens and zero active syncs.

How to export Doppler configs without leaving plaintext on disk

The main rule is to keep secret values out of the file system. Doppler's documentation strongly recommends against downloading secrets in plain text to disk, and its guidance shows process substitution so exported values pass straight from the doppler secrets download --no-file --format=json command into the next step without ever being written to a file. In practice, the pipeline reads one Doppler config as JSON on standard output and feeds it directly to bao kv put using the @ file prefix against a path such as -mount=secret with a file descriptor, so no intermediate data.json remains on a laptop, build agent or shared volume. Run the export on a host you control, disable shell history for the session, and confirm that your CI logs and terminal recordings do not capture the JSON. Ask your security team to confirm which hosts are permitted to hold Doppler service tokens at all, because the token is the credential that can read every config it is scoped to.

Dynamic secrets need a different treatment. Doppler's secrets download API returns them only when include_dynamic_secrets is set, and the leases it issues expire after 1,800 seconds by default. Do not copy those values into OpenBao as static KV entries, since they are short-lived credentials that the source system issues and revokes. Instead, inventory which Doppler configs contain dynamic secrets, then recreate each one as a database or other engine in OpenBao, such as a database secrets engine with its own role and connection configuration, so applications request fresh credentials and OpenBao handles lease expiry and revocation. Confirm the exact engine and role settings against the OpenBao migration guide and your database owner before cutover, and plan a rotation of any long-lived credential that was ever exposed through an export file or log.

What drives the cost and duration of a Doppler to OpenBao move

This table lists the factors that change the effort of moving from Doppler to OpenBao, with why each one matters and how to keep it under control. Use it to shape a written scope, because the same factor can add weeks of work in one environment and almost nothing in another. No durations or fees are given here, so ask for them against your own inventory.

Driver	Why it changes effort	How to keep it down
Number of projects and configs	Each Doppler config becomes a KV path with its own export, mapping and verification, so the count sets the bulk of the rebuild work.	Consolidate redundant configs before export and agree a naming scheme for KV paths and mounts.
Count of syncs and integrations	Every Doppler sync to a cloud platform, CI system or Kubernetes cluster must be rebuilt with a different consumer, such as an agent, template or CI variable pull.	Inventory each sync with its target and owner, then retire syncs that no longer have a consumer.
Dynamic secret types	Doppler dynamic secrets must be replaced by OpenBao secrets engines, each with its own role, connection and rotation design, and leases behave differently.	List every dynamic secret type and target system first, and start with the highest-use database or cloud roles.
Existing authentication patterns	Services that authenticate to Doppler with service tokens need new identities in OpenBao, such as AppRole for servers or Kubernetes and JWT/OIDC for workloads.	Group workloads by platform and map each group to one auth method so policies can be shared.
High availability design on Raft or PostgreSQL	Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and the choice affects node count, backup routines and operating skills.	Pick one backend your team already operates and document failover tests before cutover.
Unsealing approach	Shamir unseal keys or an auto-unseal mechanism add key custody steps, ceremonies and recovery procedures that must be designed and rehearsed.	Decide the unseal model early, record who holds keys, and test a restart before go-live.
Backup and audit requirements	Your retention rules, audit log destinations and evidence expectations determine how much logging, storage and reporting must be built around OpenBao.	Write the audit and backup requirements into the scope so they are built once rather than retrofitted.
Team skills and policy design	Path-based policies, token lifecycles and lease handling differ from Doppler's project and config model, so staff training and policy review take time.	Confirm which staff will own OpenBao after handover and pair them with the implementation work.

How the migration changes by team size and starting point

A small team with a handful of Doppler configs usually has one or two OpenBao servers, a few people who log in, and a short list of applications that read secrets. The rebuild is mostly manual: export each config, write it to a KV path, and point each application at the new path. Because the number of identities is small, the team can start with Userpass for people and tokens for early testing, and then move to AppRole for any server process. Expect the first weeks to go into deciding path names and writing policies, not into moving data.

Login method: OpenBao's auth methods documentation recommends Userpass for developer machines, so people log in with it while service processes move to AppRole.
Token handling: Long-lived tokens are the easiest starting point but the hardest to retire, so set a plan to replace them before go-live.
Path layout: One mount per environment, such as secret/ with a path per application, keeps the policy count low.
Single node: A single node is simpler to run, but it has no standby, so plan backup and restore before any application depends on it.
Manual sync: Doppler's syncs have no direct equivalent here, so each application pulls or receives its secrets through its own deployment step.

Before cutover, confirm with your OpenBao deployment that the chosen auth method and storage backend match your recovery expectations.

What usually goes wrong and how to prevent it

Doppler migrations to OpenBao tend to fail in the same few places: access that was never designed for Vault-style policies, secrets leaking during export, and gaps that only show up after cutover. Each card below names one failure and the prevention step to build into the rebuild plan before any secret moves.

Overbroad policies copied from Doppler

Doppler access is granted per project and environment, so teams often recreate it as one broad OpenBao policy per project. That gives a service read access to every path in a mount, including staging or production values it never needs. Write policies per path and per identity, deny by default, and review each one against the consumers that actually read it. Confirm that each AppRole or Kubernetes role maps to a single workload.

Secrets written to logs or disk

The export step is the most exposed moment in the migration. Doppler advises against saving plain-text downloads to the file system and shows process substitution so values never touch disk. Run the export and the bao kv put load on a locked-down workstation or bastion, avoid shell history and CI logs, and delete any temporary JSON files. Check that the import pipeline masks values and that no transcript or terminal recording captures them.

Sync targets missed until cutover

Doppler syncs push secrets into cloud platforms, CI systems and orchestrators without any application change. OpenBao does not provide those syncs, so each one needs a replacement, such as an agent, a CSI driver, or a pipeline step that reads from OpenBao. Build an inventory of every Doppler sync and integration before the first config is exported, and confirm each consumer reads from its new path before the old sync is disabled.

Dynamic credentials left active

Doppler returns dynamic secrets only when the download request asks for them, and those leases expire after 1,800 seconds by default. In OpenBao, dynamic secrets are created by database or Kubernetes engines and tracked as leases, so a rebuilt setup can leave old database users or service accounts running after the application moves. List every dynamic secret source, set lease durations deliberately, and revoke leases or retire the old credentials when each workload cuts over.

Unseal keys stored with the cluster

A self-hosted OpenBao cluster is sealed at start and needs unseal material to reopen. Keeping Shamir key shares in the same environment as the Raft data, or on the same administrator laptop, means one compromise exposes both the data and the means to decrypt it. Distribute key shares to separate custodians, store them outside the cluster, document the unseal procedure, and test a restore from backup before go-live. Confirm the chosen seal method with your own security team.

Incomplete audit trails

Doppler records activity in its own dashboard and logs, and those records do not carry over. OpenBao needs an audit device enabled before the first secret is written, so reads, writes and token events are recorded from day one. Send audit logs to a store your security team controls, set retention to match your policy, and check that a sample read from each migrated path produces an entry. Without this, the migration cannot show who accessed a secret before and after cutover.

Running Doppler and OpenBao in parallel before cutover

Keep Doppler as the source of truth until OpenBao has proven it can serve every value your applications need, and plan the cutover one config at a time. During the parallel period, OpenBao holds the same values under the KV paths you mapped, while each application still reads from Doppler. Switch a single config, such as a staging service, to read from OpenBao, then watch error rates, startup failures and secret-related incidents for a window your change board agrees on. Only move the next config once the previous one passes. Confirm in your own environment which rollback steps you can execute in minutes, including how to restore the Doppler sync or the Doppler token the application used before. Rollback to Doppler stays available until verification passes for every config that depends on it.

Test the read paths before any application depends on them. OpenBao runs an active node that holds a lock in the data store, with standby nodes that forward or redirect requests, and integrated storage (Raft) and PostgreSQL are the officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Use that to run read tests against standby nodes from your staging network, and confirm with your platform team that your load balancer and health checks route reads the way your design assumes. Do not assume write behavior or failover timing from this description. Verify both against your own cluster, including what happens to in-flight requests when the active node changes.

Decide before the parallel run who can write to each path, because during this period two systems hold the same values and drift is the main risk. Confirm that changes made in Doppler are either frozen for the migrated configs or copied to OpenBao by a documented process, and that a named owner signs off each cutover. Record the checks you ran, the rollback owner and the exact date each config moved, since auditors and your security team will ask for that evidence. Confirm with your compliance lead which records your assessment requires, and treat this log as an input to your own change management process rather than a finished audit artifact.

Questions teams ask before moving from Doppler to OpenBao

Can our team migrate from Doppler to OpenBao in-house?

Yes, many teams can, provided they have someone comfortable with Kubernetes or Linux server administration, Vault-style policies and the operational duties of a secrets manager. The work splits into three parts: exporting each Doppler config, rebuilding the structure in OpenBao, and replacing the Doppler syncs and dynamic secrets that applications depend on. The hardest part is usually not the copy of secrets but rewiring every consumer, including CI jobs and deployment pipelines, to read from the new paths. Teams without that experience often bring in an implementation partner for the design and cutover while keeping day-to-day ownership in-house.

What drives the cost of moving from Doppler to OpenBao?

The cost has components that are paid to different parties. There is the staff time to map projects, environments and configs to mounts and policies, the time to rewrite consumers, and the time to run the platform afterward. Recurring costs include the servers or Kubernetes capacity, the storage backend, backups, monitoring and upgrades. Doppler's own fees stop at cutover, but you should keep a parallel run during testing. Costs rise with the number of configs, the number of applications that pull secrets and the number of syncs to rebuild. Ask any quote to itemize scope, environments, consumers, HA design and who operates the system after go-live.

How long does a Doppler to OpenBao migration take?

Duration depends on scope rather than on a fixed figure. A small team with a few projects and one cluster will finish far sooner than an organization with dozens of projects, several environments per project, regulated change windows and many CI pipelines. Plan separate phases: inventory of projects and configs, design of mounts and policies, a non-production pilot, production cutover one application group at a time, and decommissioning Doppler after a verification period. Ask any proposal to state the phases, the number of configs in scope and the acceptance tests for each phase.

What does the team need to run OpenBao on Kubernetes?

The OpenBao Helm chart is the recommended installation path on Kubernetes, and it requires Helm 3.6 or later. Beyond the chart, you need a storage decision: integrated storage (Raft) or PostgreSQL, both of which are officially supported for high availability. Your team also needs to plan unsealing, since Shamir unseal keys or an auto-unseal design must be operated and protected. Policy skills matter because OpenBao access is controlled by policies bound to auth methods such as Kubernetes, JWT/OIDC or AppRole. Confirm these requirements against the current OpenBao documentation before you commit to a design.

Does OpenBao have a built-in importer for Doppler secrets?

No, OpenBao does not provide a Doppler importer, so the migration is a rebuild. You export each Doppler config as JSON with the Doppler CLI, then write those values into OpenBao KV paths with the bao kv put command. The CLI can read a file using the @ prefix, as in bao kv put -mount=secret foo @data.json. Because there is no importer, every project, environment and config must be mapped by hand to a mount, path and policy. Some teams script this mapping, but the mapping itself still needs review by the people who own each application.

How should we handle Doppler dynamic secrets during the move?

Doppler dynamic secrets are not copied as static values. Doppler's download API returns them only when include_dynamic_secrets is set, and those leases expire after 1,800 seconds by default. In OpenBao, the equivalent is to configure a dynamic secrets engine, such as a database or Kubernetes engine, with its own connection and role definitions, so credentials are issued and revoked by OpenBao. Plan the rebuild per backend, test lease lifetimes and revocation, and make sure applications can renew or re-request credentials. Do not export dynamic secrets to a file as if they were static.

How do we export Doppler secrets without leaving plaintext on disk?

Avoid writing plaintext exports to disk. Doppler's documentation strongly recommends against downloading secrets in plain text to the file system and shows process substitution so that values never touch the disk. Run the export in a controlled workstation or pipeline session, pipe the JSON straight into the OpenBao write command, and clear shell history and temporary variables afterward. Restrict who can run the export, log the activity under your change process and rotate the secrets that were exposed in any export that could not be avoided. Treat the exported JSON as sensitive material even when it is only in memory.

What should we confirm about OpenBao versions before migrating?

Confirm the release you intend to deploy against the OpenBao releases page before you finalize the design. OpenBao v2.7.1 was released on October 1, 2026 with security fixes. The OpenBao migration guide for moving from Vault describes an in-place upgrade from Vault Community 1.14.1 on Raft storage, and it was tested only against that version. If your source is Doppler rather than Vault, that guide does not apply directly, so confirm the target version, storage backend and auth methods in your own test environment.

What DeployOpen does in a Doppler to OpenBao engagement

DeployOpen starts with a written inventory of what Doppler holds today: every project, each environment and config, the service tokens and integrations that read from them, and any dynamic secret setups. That inventory decides the work. Because OpenBao has no Doppler importer, each Doppler config is rebuilt by hand as KV data, so the inventory is the list of paths, mounts and consumers the cutover depends on. DeployOpen then designs the KV path layout and the policy set that replaces Doppler's project and config model, mapping environments to mounts or path prefixes and deciding which workloads get read-only access to which paths. The design is agreed in writing before any secret is moved.

On the implementation side, DeployOpen installs and hardens the OpenBao deployment inside the client's own cloud account, data center or air-gapped network. That covers the storage backend choice, high availability, unseal and key custody, auth methods for servers and developer machines, audit logging and backups. DeployOpen also rebuilds the syncs and integrations that Doppler used to perform, such as CI jobs, Kubernetes workloads and cloud platforms, so they authenticate to OpenBao instead of Doppler. Where a Doppler dynamic secret was in use, the replacement database or Kubernetes secrets engine is configured and tested separately. Confirm with DeployOpen which of these items fall inside the fixed scope and which belong to an optional retainer.

The engagement ends with a documented cutover: the order in which configs move, the rollback steps for each consumer, the revocation of Doppler service tokens once each workload is confirmed, and a record of the decisions taken. Ongoing upgrades, monitoring and testing can be added under a retainer. DeployOpen does not hand over a compliance attestation; it prepares the configuration, access and logging evidence that your auditor will review. Ask for the written scope, the list of deliverables and the acceptance criteria before work starts, because those set the effort and the cost of the engagement.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Doppler to OpenBao move, we start from a written scope that maps each Doppler project and config to OpenBao mounts, paths and policies, then build and test the rebuild in your environment before any production secret is moved.

How we scope

We inventory Doppler projects, environments and configs, including which ones feed CI, cloud platforms and Kubernetes syncs
We agree in writing which applications, pipelines and dynamic secret consumers must be rebuilt on OpenBao
We define the OpenBao deployment target, storage backend, HA design and unseal approach before work starts

How we build

We stand up OpenBao in your infrastructure and configure KV mounts, auth methods and policies that mirror the agreed mapping
We script the export of each Doppler config to JSON and its import into OpenBao paths, avoiding plain-text files on disk
We rebuild syncs and dynamic secret workflows, then test access, rotation and lease revocation in a non-production environment

How we hand over

We document the path layout, policies, auth roles, backup and restore steps and the runbook for unsealing and upgrades
We provide evidence of configuration and test results so your security and compliance teams can review them
We walk your operators through the handover and confirm which Doppler items were retired and when access was revoked

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
We can help your team plan OpenBao version upgrades and review new security releases as they are published
Compliance readiness work prepares systems and evidence for your independent auditors, who issue any reports or certifications

Migrate from Doppler to OpenBao