How do you handle secrets/env files properly in a team repo?

[discovicke]

Select Topic Area

Question

Body

I know the basics: never commit .env files, add them to .gitignore. But I'm curious how real teams handle this beyond that.
For example:

Do you use a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault)?
How do you share secrets with new team members onboarding?
Do you use .env.example files as a template?
Any workflows around rotating secrets when someone leaves the team?

I'm currently working on an ASP.NET project and want to build good habits early. What's worked for your team?

[shivrajcodez]

Good question. Most teams handle this in a few simple layers.

1. Local development
   .env files stay in .gitignore, and the repo usually includes a .env.example file that lists all required variables without values. This helps new developers know what they need to configure.

2. Secrets in production
   Real deployments typically pull secrets from a secrets manager or environment variables, not files. Common options are AWS Secrets Manager, Azure Key Vault, or platform-level environment variables.

3. CI/CD pipelines
   Build and deployment secrets are stored in the CI system (for example GitHub Actions secrets) and injected during runtime.

4. Onboarding and rotation
   New developers usually get access through a password manager or internal docs rather than sharing raw secrets. If someone leaves the team, credentials are rotated and access is revoked.

In practice the common setup is:

.env ignored

.env.example committed

secrets stored outside the repo

CI/CD injecting them during deployment

That pattern scales pretty well from small projects to larger teams.

[discovicke]

Thank you, the layered breakdown makes this really easy to understand! The summary at the end is a perfect mental model to keep in mind:

.env ignored, .env.example committed, secrets outside the repo, CI/CD injecting them at runtime.

Simple enough to follow from day one.

[arveyy]

In most professional teams, handling secrets goes beyond just ignoring .env files. Many teams use a secrets manager, such as Vault, AWS Secrets Manager, or Azure Key Vault, to securely store and manage credentials. Sharing secrets with new team members is usually done through controlled access in these tools rather than sending files over chat or email.

Using a .env.example file as a template is common practice, as it documents required variables without exposing sensitive data. Teams also often implement workflows for rotating secrets when someone leaves, ensuring old credentials are revoked and replaced. Building these habits early, especially in an ASP.NET project, helps maintain security and scalability as the team grows.

[discovicke]

Thank you! The point about sharing secrets through controlled access instead of chat or email is something I'll make a habit of from the start. It's easy to cut corners there without realizing the risk.

Good to know .env.example is standard practice too, it felt intuitive to add it to my ASP.NET project when I became "env dependent". Always nice to get an indication that I didn't do "wrong" in that regard! :)

[Sudip-329]

Hi,

You’re already on the right track by never committing .env files and using .gitignore. In professional teams, managing secrets goes beyond that. Here’s a common workflow that works well:

---

1️⃣ Use a secrets manager

Most teams rely on centralized secrets storage instead of local .env files for sensitive data. Popular options include:

• HashiCorp Vault – cross-platform, dynamic secrets
• AWS Secrets Manager / Parameter Store – great if your infrastructure is on AWS
• Azure Key Vault – for Azure environments
• GitHub Actions Secrets – for CI/CD pipelines

These allow secure access control, logging, and automatic rotation.

---

2️⃣ Sharing secrets with team members

• Grant access to the secrets manager per user or per role
• For onboarding, new developers get access credentials (not raw secrets)
• Avoid sending .env files over chat or email

---

3️⃣ Use .env.example as a template

• Always commit a .env.example with placeholder values (e.g., DB_PASSWORD=changeme)
• This makes onboarding easy and ensures everyone knows which keys are required

---

4️⃣ Rotation and revocation

• When someone leaves, revoke their access in the secrets manager
• Rotate keys or passwords if needed
• Automate rotation if possible (many secrets managers support this)

---

5️⃣ CI/CD Integration

• CI/CD pipelines should pull secrets at runtime instead of storing them in the repo
• Avoid hardcoding any credentials in code or configuration files

---

6️⃣ Optional workflow tip

For local development, you can still use a .env.local or similar, excluded from git, while CI pulls from the secrets manager. Some teams even have environment-specific .env files (development, staging, production) stored securely.

---

💡 Summary:

• Never commit secrets
• Use a secrets manager for access control
• Provide .env.example as a template
• Rotate/revoke secrets when team members change

This workflow scales well and keeps secrets secure even in a growing team.

If this answer helps you, please mark it as the accepted answer so others can benefit too.

[discovicke]

This is a really complete answer, thank you!

I'm working on an ASP.NET project right now and the distinction between local .env.local for development vs a secrets manager in CI/CD is something I hadn't thought about clearly before. It makes the whole setup feel a lot less intimidating.

The rotation and revocation section is also something I wouldn't have thought to ask about, but it's clearly important to get right early. Marking this as accepted!

[mithatakbulut]

I ended up building an OSS tool around pretty much this exact problem.

The specific case I'm trying to solve is: a code change introduces a new local env requirement, someone pulls it, and then has to figure out which value they're missing and ask around for it.

local.env connects that requirement to GitHub and lets the team resolve/sync the local value through the CLI. It's intentionally only for local development, not production secrets.

If you're still dealing with this problem, I'd genuinely love to know if this approach would fit your workflow, I'm looking for a handful of teams to break the first public version.

https://github.com/mithatakbulut/local.env