Secrets management without a vault platform

HashiCorp Vault solves real problems at scale. For a 5-engineer team running 3 services, deploying and operating Vault is more work than the problems it solves. Same for paid vault platforms that charge per-secret.

Small teams can manage secrets safely with simpler tooling. The patterns below cover most situations.

What "safe" means for secrets

1. Secrets never in git history (even old branches).
2. Secrets never in plain text on developer machines without justification.
3. Secrets rotatable without redeploying entire codebase.
4. Access auditable — who has what secret.
5. Backup recoverable in case of key loss.

Pattern 1: cloud-native secrets manager

If you're already on AWS, GCP, Azure, or Yandex Cloud, their secrets manager is fine:

• AWS Secrets Manager — $0.40/secret/month, $0.05 per 10K API calls.
• AWS Systems Manager Parameter Store — free, simpler.
• GCP Secret Manager — $0.06/secret/version/month.
• Yandex Cloud Lockbox — Russian equivalent.

Apps fetch secrets at startup via SDK. IAM controls access.

Right for: Cloud-hosted apps, 5-50 secrets, no special compliance.

Pattern 2: SOPS for git-committed encrypted secrets

Mozilla SOPS encrypts YAML/JSON files using age, GPG, AWS KMS, or others. Encrypted file is committed to git. Decryption requires the key.

# Encrypt
sops --age-recipients age1abc... -e -i config.prod.yaml

# Decrypt and run
sops -d config.prod.yaml | yq .DATABASE_URL

Benefits:

• Secrets versioned with code, but encrypted.
• Each developer has their own age key.
• No external service dependency.
• Works offline.

Drawbacks:

• Rotation requires re-encrypting and committing.
• Key management on developer machines.

Right for: Small teams, infrastructure-as-code, low-frequency secret changes.

Pattern 3: 1Password for team secrets

1Password (or Bitwarden) for non-production credentials, shared team accounts, individual developer machine credentials.

• 1Password CLI integrates with shell — secrets fetched on demand.
• Audit log built-in.
• Per-user access control.

Right for: Team-shared credentials (Stripe, Slack workspaces, vendor accounts).

Pattern 4: GitHub/GitLab encrypted secrets

For CI/CD, GitHub Actions and GitLab CI have built-in encrypted secret storage.

• Set via web UI or API.
• Injected into CI environment as env vars.
• Cannot be read back, only used.

Right for: CI/CD-only secrets (deploy keys, registry tokens).

Pattern 5: env files done right

Local development uses .env files. Just make sure:

• .env in .gitignore always.
• Provide .env.example with non-secret structure.
• Document where to get secrets (1Password vault).
• Never copy from prod env to local — keep separate sets.

The mistake of ".env in git history"

One commit with secrets, even if reverted, exposes them forever. To fix:

• Rotate every secret immediately.
• Use BFG Repo-Cleaner or git filter-repo to expunge from history.
• Force-push (with coordination).
• Notify GitHub via secret scanning — they may rotate API keys for you.

Combining patterns

Typical small team setup:

• Cloud secrets manager for production runtime.
• SOPS for infrastructure config in git.
• 1Password for team-shared accounts and vendor credentials.
• GitHub Actions secrets for CI/CD.
• .env files for local development.

Five tools, each clearly scoped. Avoid one big system trying to do all five.

Access control

• Production secrets: 1-3 people, behind MFA.
• Staging: dev team.
• CI/CD: machine-only access via repo secrets.
• Vendor accounts: minimum scope, MFA required.

Rotation

Quarterly rotation of all secrets at minimum. Annually if you have less time. Some critical ones (master DB credentials, root API keys) should rotate more often.

Automate rotation where possible (cloud secrets managers handle this for some integrated services).

Audit

• Quarterly review of who has access to which secrets.
• Remove leavers immediately.
• Log every secret fetch (cloud secrets managers do this).
• Anomaly detection on fetch patterns.

When to graduate to Vault

HashiCorp Vault becomes worth its complexity when:

• 30+ engineers and 100+ secrets.
• Compliance requirements (PCI, SOC 2 with strict controls).
• Dynamic secrets (DB credentials issued per-request).
• Multi-cloud setups needing unified secret management.

Until then, simpler tools handle the job.

Verdict

Small teams don't need Vault. Cloud secrets manager + SOPS + 1Password + CI repo secrets + clean .env practices cover 95% of small-team secret management. Set up these five layers, enforce no-secrets-in-git, rotate quarterly, audit access. Add Vault only when scale demands it.