{"schemaVersion":"1.0","type":"TechArticle","types":["Article","TechArticle"],"slug":"secrets-management-for-small-teams-from-env-files-to-a-real-vault-opa0r","url":"https://zyvop.com/secrets-management-for-small-teams-from-env-files-to-a-real-vault-opa0r","title":"Secrets Management for Small Teams: From .env Files to a Real Vault","subtitle":"A practical path for small teams: lock down .env files, encrypt secrets in git, adopt a managed store, and know when a vault is worth it.","tldr":"Shared .env files work until someone leaves, a key leaks, or a commit goes public. This guide lays out a staged path for small teams, from basic hygiene and encrypted files to managed secret stores and Vault, with what each stage costs and when to move on.","keywords":["sops","security","DevOps","secrets-management","vault","Tutorial"],"entities":["Anshu Pathak","sops","security","DevOps","secrets-management","vault","Tutorial","ZyVOP"],"keyTakeaways":["Every small team starts the same way.","Someone creates a .env file, it works, and it gets copied to the next developer over chat.","A year later the file lives on a dozen laptops, nobody remembers which database password is current, and a departing teammate still has every key."],"headings":["Why .env files stop working","The goals, and a ladder to reach them","Stage 1: Hygiene (this week, nearly free)","Stage 2: Encrypted secrets in git (SOPS + age)","Stage 3: A managed secret store","Stage 4: A real vault, and dynamic secrets","CI/CD: stop storing long-lived cloud keys","Practices that matter at every stage","A realistic migration plan","Wrapping up"],"outboundLinks":[],"contentText":"Every small team starts the same way. Someone creates a .env file, it works, and it gets copied to the next developer over chat. A year later the file lives on a dozen laptops, nobody remembers which database password is current, and a departing teammate still has every key. You don't need a platform team to fix this. You need a staged path: cheap habits first, then encrypted files, then a managed store, and a full vault only when your requirements demand one. This post walks through each stage, what it costs, and how to know when to move on. Why .env files stop working A .env file is a fine way to hold local development defaults. It fails as the way a team shares real secrets: No audit trail. When production credentials change, you can't tell who changed them or who has read them. No clean revocation. When someone leaves, you can't know which copies of the file exist, so the only safe move is rotating every secret. Easy to commit by accident. Git keeps history. Deleting a file in a later commit doesn't remove the secret from earlier ones. Drift. Staging, production, and each laptop slowly disagree. The scale of the problem is large. GitGuardian's 2026 report found: About 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the year before. 64% of the secrets it confirmed as valid in 2022 were still exploitable in January 2026. Detecting a leak is not the same as rotating the credential. Hardcoded secrets in about 32% of internal repositories, against about 6% of public ones, so private repositories are not safe either. Commits co-authored by an AI coding assistant (the report measured Claude Code) leaked secrets at about twice the baseline rate: 3.2% versus 1.5%. GitGuardian sells secrets-detection tools, so treat the numbers as indicative. The goals, and a ladder to reach them Whatever tools you choose, you are trying to get five things: Secrets stay out of git (or only appear encrypted). Least privilege: each person and service gets only the secrets it needs, per environment. Fast rotation and revocation: replacing a secret is routine, not an emergency. An audit trail: you can see who accessed or changed what. Small blast radius: where possible, credentials are short-lived, so a leak expires on its own. You don't need all five on day one. Here is a ladder most small teams can climb in order: flowchart LR S0[\"Stage 0<br/>.env files shared by chat\"] --> S1[\"Stage 1<br/>Hygiene: gitignore, scanning,<br/>separate dev and prod secrets\"] S1 --> S2[\"Stage 2<br/>Encrypted secrets in git<br/>(SOPS + age)\"] S1 --> S3[\"Stage 3<br/>Managed secret store<br/>(cloud or SaaS)\"] S2 --> S3 S3 --> S4[\"Stage 4<br/>Short-lived credentials,<br/>rotation, self-run vault\"]Stage 1: Hygiene (this week, nearly free) Do these first, whatever else you choose: Ignore real .env files and commit a template. The template lists names only: # .gitignore .env .env.* !.env.example# .env.example (committed: names only, no real values) DATABASE_URL= STRIPE_SECRET_KEY=Separate secrets per environment. Production credentials should never appear on a development laptop. Turn on secret scanning. On GitHub, secret scanning and push protection are free for public repositories. For private repositories you need GitHub Secret Protection, which was listed at $19 per active committer per month when it opened to Team plans in 2025, so check the current price. Open-source scanners are a free alternative: Gitleaks is fast enough for a pre-commit hook, and TruffleHog can scan in CI and check whether a detected secret is still live. Take an inventory. List every secret, what it unlocks, who uses it, and where it lives. You can't protect or rotate what you haven't listed. Keep human logins in a password manager, not in the same system as application secrets. If a secret ever reached git or chat, rotate it first. Cleaning history is secondary. The 64% figure above shows how often leaked credentials stay valid because nobody rotated them. Stage 2: Encrypted secrets in git (SOPS + age) If you have no budget or appetite for running a server, you can commit secrets to your repository encrypted. SOPS, a CNCF sandbox project, encrypts only the values in a YAML, JSON, or env file and leaves the keys readable, so diffs and code review still work. It pairs well with age, a small modern encryption tool that gives each developer a keypair. # .sops.yaml: who can decrypt which files creation_rules: - path_regex: secrets/.*\\.yaml$ age: >- age1alice..., age1bob...sops secrets/prod.yaml # edit: decrypts in your editor, re-encrypts on save sops exec-env secrets/prod.yaml './start.sh' # run a command with the values as env vars (use flat KEY: value pairs)What you get: secrets versioned alongside the code that needs them, nothing to host, and a natural fit for GitOps workflows. What you don't get: No audit log of who read a secret. Git only records who changed the file. No dynamic or auto-rotating credentials. Offboarding takes more than deleting a key. Remove the person's key as a recipient, run sops updatekeys, then run sops rotate to generate a new data key, in that order, as the SOPS docs recommend. Then rotate the underlying secrets too, because the person's old key can still decrypt earlier commits in your history. This stage suits small teams who want to stop sharing plaintext files with the least possible machinery. Stage 3: A managed secret store A managed store keeps secrets out of your repository entirely, controls access centrally, and, depending on the product and plan, logs who touched what. There are two families. Cloud-native services such as AWS Secrets Manager, Google Cloud Secret Manager, and Azure Key Vault. Your workloads authenticate with their cloud identity (an IAM role, for example), so the app doesn't need a static credential just to fetch its secrets. AWS offers two options with different trade-offs. At the time of writing: Secrets Manager charges $0.40 per secret per month plus $0.05 per 10,000 API calls in us-east-1, and offers managed rotation, such as for database passwords. Parameter Store (standard tier) is free for storage and API calls, with 4 KB values and up to 10,000 parameters (KMS request charges may still apply to encrypted values). It has no automatic rotation, so it suits non-rotating values. Developer-focused platforms such as Doppler, Infisical, 1Password's secrets tooling, and Bitwarden Secrets Manager. They organize secrets by project and environment, inject them into local runs and CI with a CLI, and integrate with common hosts. Doppler is a proprietary hosted service, while Infisical is open source and can be self-hosted or used as a cloud service. Free tiers suit small teams, but governance features such as SSO, audit logs, and fine-grained access control are often on paid plans. Published prices vary between sources, so check each vendor's pricing page before you commit. The pattern that makes either family safer, wherever the platform supports it, is identity-based access. The workload proves who it is to the platform, and the platform hands back short-lived credentials, which avoids the \"secret zero\" problem of needing one secret to fetch all the others: sequenceDiagram participant App as App or job participant IdP as Cloud identity (IAM role) participant SM as Secret manager App->>IdP: Prove identity (instance or pod role) IdP-->>App: Short-lived credentials App->>SM: Request the database password SM-->>App: Secret value (access is logged)For most teams of a few engineers, this stage is usually enough. Stage 4: A real vault, and dynamic secrets HashiCorp Vault and its fork OpenBao go further. Beyond storing secrets, they can create credentials on demand: a database login that exists for an hour and is then revoked, for example. They also handle certificates, encryption as a service, and detailed policy across clouds. Consider this stage when you have specific needs, such as dynamic database credentials, a multi-cloud estate, strict compliance requirements, or many services that need tightly scoped, short-lived access. Know what you are signing up for: You run a critical service. High availability, backups, unsealing, upgrades, and monitoring become your job. If the vault is down, new deployments and secret reads fail. The licensing landscape has shifted. HashiCorp moved Vault from the Mozilla Public License to the Business Source License in August 2023. OpenBao is a Linux Foundation fork of the last MPL-licensed release (Vault 1.14) and keeps the open license. The BSL restricts offering a competing managed service, so a company running Vault for its own use is generally not the target. Check the terms with whoever handles legal for you. The simple managed option is gone. HashiCorp ended sales of HCP Vault Secrets on June 30, 2025, and retired it by July 1, 2026. HashiCorp's remaining hosted option, HCP Vault Dedicated, is aimed at larger organizations, and third-party roundups put its entry pricing well above the SaaS tools in Stage 3. If you aren't sure you need this stage, you probably don't. Move up because of a requirement, not because of team size. CI/CD: stop storing long-lived cloud keys Your CI system is often one of the most privileged secret holders you have. Instead of copying a cloud access key into repository settings, use OpenID Connect (OIDC). The workflow requests a short-lived token from GitHub, and your cloud provider exchanges it for temporary credentials scoped to one role: # part of a deploy job definition permissions: id-token: write # lets the job request an OIDC token contents: read steps: - uses: aws-actions/configure-aws-credentials@v6 # pin to a reviewed version or commit SHA with: role-to-assume: arn:aws:iam::123456789012:role/deploy-prod aws-region: us-east-1OIDC isn't automatically safe. AWS's IAM guidance recommends temporary credentials and least privilege, and its OIDC setup documentation covers restricting a role's trust policy by audience and subject. In practice: Grant id-token: write only to the job that needs it. Write the trust policy so only the intended repository and branch (or environment) can assume the role. Pin third-party actions to reviewed versions, and keep the role's permissions small. Recent versions of the AWS credentials action (v5 and later) also need a runner at version 2.327.1 or later, which matters if you host your own runners. Practices that matter at every stage Rotate on a schedule for high-value secrets, and immediately after a departure or a suspected leak. Design for rotation by letting two valid secrets overlap during the changeover. Prefer identity to static secrets wherever the platform supports it. Keep secrets out of logs and command lines. Environment variables are convenient, but child processes inherit them and crash dumps can capture them. Don't treat Kubernetes Secrets as encrypted. By default they are only base64-encoded and stored unencrypted in etcd. Enable encryption at rest (existing Secrets must be rewritten to be encrypted), or sync from a real store with a tool such as External Secrets Operator. Plan for lost keys. Back up your age keys and your secret store's recovery credentials, and keep a documented break-glass procedure. Rehearse a leak. Revoke, rotate, check access logs, then clean up history. In that order. A realistic migration plan Week one: inventory your secrets, add .gitignore rules and scanning, and rotate anything that has ever been in git or chat. Weeks two and three: move production secrets into encrypted files or a managed store, and have the app receive them at deploy time instead of from a shared file. Next: switch CI to OIDC, delete static cloud keys, and enable managed rotation for database credentials. Later, if needed: evaluate a vault for dynamic secrets once a concrete requirement appears. Wrapping up The goal isn't the fanciest tool. It is making the safe path the easy one: secrets that aren't in git, access that follows identity, credentials that expire, and a rotation routine your team has practiced. Start with hygiene, pick the lightest stage that meets your needs, and add machinery only when a real requirement shows up.","contentHash":"sha256:866a1c45c53503b4a5a58e963e80c0886857c13cc896b96a85b6fddc6fd14673","authorName":"Anshu Pathak","authorUrl":"https://zyvop.com/author/anshu","authorSameAs":["https://www.linkedin.com/in/anshu-pathak-zyvop/"],"category":"Tutorial","tags":["sops","security","DevOps","secrets-management","vault"],"audience":"Software engineers and developers building applications with Tutorial","tone":"Practical and evidence-based engineering guidance","readingTimeMinutes":8,"wordCount":2022,"faqs":null,"primaryTopic":"Tutorial","publishedAt":"2026-10-30T05:38:18.591Z","updatedAt":"2026-10-30T05:38:18.591Z","canonicalUrl":"https://zyvop.com/secrets-management-for-small-teams-from-env-files-to-a-real-vault-opa0r"}