Secrets Management for SaaS: Vault, AWS Secrets Manager, Doppler

What you need to know

• Environment variables in .env files have no audit trail, no rotation mechanism, and no access control granularity. They are a start point, not a destination.
• Doppler is the easiest migration path from .env files for startups and small teams, with good developer experience and no infrastructure to manage.
• AWS Secrets Manager is the right choice for AWS-native teams who want managed rotation and IAM-based access control.
• HashiCorp Vault is appropriate for teams with serious compliance requirements or complex multi-cloud needs, but requires significant operational investment.
• All three options should enforce least-privilege access: each service gets access only to the secrets it needs, not all secrets.

The core argument

The progression of secrets management in most SaaS products follows a predictable path. Start with .env files during development. Add those to the deployment configuration as environment variables. Discover, months or years later, that there is no audit trail, no rotation process, and more engineers with access to production secrets than is comfortable. The migration from ad-hoc environment variables to a proper secrets manager is deferred repeatedly because it feels like infrastructure work with no user-facing benefit, until the security audit, the SOC 2 assessment, or the incident that makes the audit trail matter.

The right time to adopt a secrets management tool is before the audit, not during it. The migration from .env files to Doppler or AWS Secrets Manager is a half-day project for most products and produces immediate security and operational benefits: every secret read is logged, access can be revoked without a deployment, and new team members get scoped access rather than a copy of the production .env file emailed to them.

The choice between the three options is primarily about team context. Doppler wins for teams that want to move quickly and want a developer-friendly workflow. AWS Secrets Manager wins for teams already using AWS and wanting native integration without a third-party service. Vault wins for teams with strict data residency or compliance requirements that prohibit third-party secret storage. For Velmora, we moved from .env files to Doppler early and never regretted the decision. The audit log alone was worth the change, and the ability to give contractors scoped access without sharing the main credentials file removed a significant operational risk.

Common mistakes

1. Not implementing rotation before a compliance audit requires it. Rotation is the feature that most teams skip when initially setting up secrets management because it requires the most engineering coordination. When rotation is implemented after the fact, the rotation logic must be verified against every service that reads the secret. Build rotation support from the start: test that the application handles secret rotation (reads the new value within the rotation window) before a rotation is required by a security policy.

1. Granting every service access to every secret. A secrets manager with a single access policy that grants all services access to all secrets is only marginally better than a shared .env file. The operational investment in secrets management produces its security return through least-privilege access. Each service should be granted access only to the specific secrets it requires. This limits the blast radius of a single service compromise.

1. Keeping local .env files after migrating to a secrets manager. After migrating to a central secrets manager, local development .env files with real credentials often persist on developer machines as "convenient" fallbacks. These files are not audited, not rotated, and not subject to the access controls in the secrets manager. Migrate local development to use the secrets manager's CLI (Doppler's CLI, for example, injects secrets directly without an .env file) and remove real credentials from local .env files.

1. Not testing secret rotation before enabling it. Automatic rotation that the application cannot handle produces an outage when the rotation fires. Test rotation in staging before enabling it in production: execute a manual rotation and verify that the application reads the new credential within the rotation window without errors. This test is especially important for database credentials where the connection pool holds connections with the old credential.

1. Using a single secret for multiple environments. Using the same database password or API key across development, staging, and production means a leak in any environment exposes all of them. Maintain separate secret values per environment and separate access policies per environment. A developer who needs staging access should not automatically have production access.

Where to start

1. Migrate development environment secrets to Doppler in one day. Create a Doppler project, add the secrets from the .env file, install the Doppler CLI, and update the application startup to use doppler run -- npm start instead of reading the .env file. Verify the application works. Delete the .env file from the development environment. This is the lowest-effort first step and establishes the pattern for staging and production.

1. Audit who currently has access to production secrets. List every person and service that has access to production environment variables. For each, determine whether access is still required and at what granularity. Revoke access for any person or service that no longer needs it. Document the access policy so it can be reviewed and maintained as the team changes.

1. Build a rotation test for the highest-value secret. The production database credential is typically the highest-value secret. Write a test that: rotates the credential in staging, verifies the application reads the new credential without an error, and confirms that connections using the old credential fail. Run this test before enabling automatic rotation in production.

Related reading

• Secrets in CI: The Patterns That Avoid Leaks
• Server Side Request Forgery: The Quiet Killer in SaaS Integrations
• Right to Be Forgotten: How to Implement It Without Pain
• SOC 2 Type I vs Type II: A Founder's Guide to Both