Running Doppler or Vault Across a Dev Shop's Client Codebases

The best time to decide how a client's secrets will be stored is before the first commit, not after a contractor asks where the staging database password lives. Set up an isolated space for that client's credentials from day one, whether that's a dedicated Doppler project or a Vault namespace, so the habit of separating client A's secrets from client B's never has a chance to slip.

Doppler's low setup cost matters most when your team is context-switching between clients throughout the week. A new project can have its own Doppler project running in minutes, synced to that client's CI pipeline and hosting platform, without a dedicated engineer standing up infrastructure first. For a shop where billable hours matter, the time you don't spend configuring a vault is time you can spend on the client's actual product.

If your shop takes on ongoing infrastructure ownership for a client, not just a build-and-hand-off engagement, Vault's dynamic secrets become worth the operational cost. A Vault-issued database credential that expires automatically after a few hours means a compromised staging environment doesn't hand an attacker a password that still works next week. That protection matters more the longer you expect to be the one running a client's systems.

A clean handoff means the client can operate their own systems the day you leave, with no dependency on a tool only your shop's account can access. Doppler's project-level structure makes ownership transfer straightforward: change the account owner, and the client's credentials go with it. Vault, especially a self-hosted instance your shop stood up, is harder to transfer cleanly, since the client inherits the operational burden of running it themselves.

For a clean handoff at the end of an engagement:

• Transfer ownership of the client's Doppler project so their credentials go with it and they depend on no account of yours.
• Plan the migration early if you self-hosted Vault for them, since it's harder to transfer cleanly than a hosted project.
• Revoke each contractor's access to the client's secrets the same day their work ends, not at the end of the billing cycle.
• Rotate any credential a contractor may have copied locally rather than assuming those copies were deleted.
• Check that no previous client's keys survived in reused boilerplate or staging configuration.

Many shops end up running Doppler as the default for new engagements, reserving Vault for the handful of clients whose infrastructure they manage long-term and whose systems justify dynamic, short-lived credentials. Deciding this per client, rather than picking one tool for the whole shop, keeps setup cost proportional to what each engagement actually needs.

Shops that reuse boilerplate across engagements sometimes copy a staging environment's configuration wholesale into a new client's project, variable names and all. If the old client's Stripe or SendGrid key was still active in that staging config, it comes along for the ride, sitting unused in a new client's environment until someone stumbles on it during a security review, or worse, until it gets triggered by accident.

The fix is a short checklist applied to every new engagement: before a new client's environment goes live, confirm every variable in it belongs to that client specifically, not to whatever template the shop started from. A Doppler project created fresh per client, rather than duplicated from an old one, avoids this by construction, since there's nothing to carry over in the first place.

A new client engagement kicks off on a Monday. Before any code is written, create that client's dedicated project, invite only the engineers actually staffed on the work, and add the first known credential, typically a staging database password or a third-party API key the client has already provided. This takes less time than the client kickoff call itself.

As the engagement grows, new integrations get added to that same scoped project rather than a shared one, and by the time the project wraps, every credential tied to it lives in one place instead of scattered across whoever happened to set each one up. Handoff at the end becomes a single ownership transfer instead of a scavenger hunt through old Slack messages and forgotten configuration files.

Setting up a dedicated project or namespace for a new client takes time, and so does tearing one down cleanly when the engagement ends. That time belongs in the estimate you send the client, not in the hours you quietly absorb between billable work.

For a fixed-bid engagement, add a line item for initial secrets setup and final handoff, even if it's small. For a retainer, treat ongoing access changes, adding a new contractor, revoking an old one, rotating a credential after a scope change, as part of the monthly retainer rather than a favor you do for free. Clients rarely push back on this once you frame it as part of keeping their systems auditable, not as padding.

If a client specifically asks for a dedicated Vault namespace instead of a shared Doppler team plan, that request usually comes with more operational work attached, and the estimate should reflect that difference before you agree to it.