SpiritCode.blog

Secret Management for Startups: Stop Hardcoding Credentials

Secret Management for Startups: Stop Hardcoding Credentials

Meta description: I learned the hard way why secret management for startups matters — here’s the exact setup I use in production to keep API keys and credentials safe from day one.

Last updated: May 14, 2025

Early in my startup career, I pushed a commit to a public GitHub repo with an AWS access key hardcoded in a .env file. Within 11 minutes — I checked the CloudTrail logs — someone had spun up 47 EC2 instances in regions I’d never even used. The bill hit $3,200 before I noticed the alert. That was the day I took secret management seriously.

If you’re building a startup and still storing API keys in .env files committed to version control, or sharing passwords over Slack, this guide is for you.

TL;DR

  • Never hardcode secrets or commit .env files — use a dedicated secrets manager from day one.
  • HashiCorp Vault and AWS Secrets Manager are the two most battle-tested options for early-stage startups.
  • Rotate secrets automatically and audit access logs regularly — these two habits prevent 80% of credential-related incidents.

Why Secret Management Matters for Startups

Most founding teams move fast and cut corners on security. I get it — you’re trying to ship, not write security policies. But credential leakage is one of the few mistakes that can kill a company overnight. A leaked Stripe API key, a exposed database password, or a compromised OAuth token can lead to data breaches, service outages, and regulatory penalties.

The 2023 Verizon Data Breach Investigations Report found that stolen credentials were involved in over 49% of breaches. Startups are disproportionately targeted because attackers know early-stage teams rarely have security tooling in place.

[SOURCE: https://www.verizon.com/business/resources/reports/dbir/]

The good news: setting up proper secret management takes less than a day, and the free tiers of most tools are more than enough to get started.

Prerequisites

Before diving in, make sure you have:

  • A GitHub, GitLab, or Bitbucket account with at least one active repo
  • Basic familiarity with the command line
  • Either an AWS account (for AWS Secrets Manager) or Docker installed (for self-hosted Vault)
  • Node.js 18+ or Python 3.10+ for the code examples

Step-by-Step: Setting Up Secret Management

Step 1: Audit Your Current Secrets Exposure

Before adding tooling, find out what you’re already leaking. I run this command on every new codebase I join:

git log --all --full-history -- "*.env" | head -20
git grep -r "AKIA" .          # AWS key prefix
git grep -r "sk_live" .       # Stripe live key prefix
git grep -r "password" . --include="*.js"

Also run truffleHog for a deeper scan:

pip install trufflehog
trufflehog git file://. --only-verified

When I first ran this on a 6-month-old codebase, it flagged 14 secrets — including a Twilio auth token we thought we’d rotated but hadn’t removed from git history.

Step 2: Add .gitignore Rules Immediately

This is the fastest win. Add these lines to your .gitignore right now:

# Secrets
.env
.env.*
!.env.example
*.pem
*.key
secrets/
config/secrets.yml

Also create a .env.example with placeholder values so your teammates know what variables exist without exposing real values:

# .env.example
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_your_key_here
AWS_ACCESS_KEY_ID=your_key_here

Commit .env.example to the repo. Never commit .env.

Step 3: Choose Your Secrets Manager

For most early-stage startups, I recommend one of two paths:

Option A — AWS Secrets Manager (if you’re already on AWS):

# Store a secret
aws secretsmanager create-secret \
  --name prod/myapp/stripe \
  --secret-string '{"key":"sk_live_xxxxx"}'

# Retrieve it in your app
aws secretsmanager get-secret-value \
  --secret-id prod/myapp/stripe \
  --query SecretString \
  --output text

Cost: ~$0.40/secret/month. For a typical startup with 20–30 secrets, that’s under $15/month.

Option B — HashiCorp Vault (self-hosted on Docker):

docker run -d \
  --name vault \
  -p 8200:8200 \
  -e 'VAULT_DEV_ROOT_TOKEN_ID=myroot' \
  hashicorp/vault:1.16.0

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='myroot'

# Write a secret
vault kv put secret/myapp/stripe key=sk_live_xxxxx

# Read it back
vault kv get -field=key secret/myapp/stripe

[SOURCE: https://developer.hashicorp.com/vault/docs/get-started/developer-qs]

Step 4: Integrate Secrets Into Your App at Runtime

The goal is to never have a secret touch disk or environment variables in plaintext. Here’s how I do it in a Node.js app with AWS Secrets Manager:

const { SecretsManagerClient, GetSecretValueCommand } = require("@aws-sdk/client-secrets-manager");

const client = new SecretsManagerClient({ region: "us-east-1" });

async function getSecret(secretName) {
  const response = await client.send(
    new GetSecretValueCommand({ SecretId: secretName })
  );
  return JSON.parse(response.SecretString);
}

// Usage at startup
const secrets = await getSecret("prod/myapp/stripe");
const stripe = require("stripe")(secrets.key);

This pattern fetches secrets at boot time and injects them into your services — no .env file needed in production.

Step 5: Set Up Automatic Rotation

One of the most overlooked features. In AWS Secrets Manager:

aws secretsmanager rotate-secret \
  --secret-id prod/myapp/db-password \
  --rotation-rules AutomaticallyAfterDays=30

For database passwords, AWS has built-in Lambda rotators for RDS. I enable these on every new project — it takes 10 minutes and eliminates a whole class of credential staleness risk.

Real-World Tips I Use in Production

Namespace your secrets consistently. I always use the pattern env/appname/service — for example prod/payments-api/stripe. This makes IAM policies much easier to write.

Use IAM roles, not access keys, for services running on AWS. When I migrated our EC2 services from access keys to instance roles, I eliminated 12 long-lived credentials from our secrets manager entirely.

Separate secrets by environment. Never reuse a production secret in staging. I keep three separate paths: dev/, staging/, and prod/. This sounds obvious, but I’ve seen three funded startups get breached because staging had production DB credentials.

Security Note: Even with a secrets manager, your secrets are only as safe as your IAM policies. Least-privilege access is non-negotiable — each service should only be able to read the exact secrets it needs, nothing more.

Common Errors and How I Fixed Them

Error: AccessDeniedException when reading from Secrets Manager

This usually means the IAM role or user doesn’t have secretsmanager:GetSecretValue on the specific ARN. Fix it by adding this to your IAM policy:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/myapp/*"
}

Error: Vault returning 403 permission denied on kv get

In Vault, the default policy doesn’t grant access to secret/ paths. I always run:

vault policy write myapp-policy - <<EOF
path "secret/data/myapp/*" {
  capabilities = ["read"]
}
EOF
vault token create -policy=myapp-policy

Gotcha: Secrets Manager caches secrets for up to 5 minutes if you use the SDK’s built-in caching client. In high-security contexts where you’ve just rotated a compromised secret, force a fresh fetch with ForceDeleteWithoutRecovery or bypass the cache explicitly.

[INTERNAL LINK: related article on IAM best practices for startups]

FAQ

Q: What is the best secret management tool for early-stage startups? A: For startups already using AWS, AWS Secrets Manager is the easiest to set up and integrates natively with IAM, Lambda, and RDS rotation. For cloud-agnostic or self-hosted setups, HashiCorp Vault offers more flexibility. Both are production-grade options I’ve used in real deployments.

Q: How do I prevent developers from accidentally committing secrets to GitHub? A: Install pre-commit hooks using the pre-commit framework with the detect-secrets plugin. Run pip install detect-secrets && detect-secrets scan > .secrets.baseline, then add the hook to your .pre-commit-config.yaml. Also enable GitHub’s built-in secret scanning under Settings → Code security.

Q: Is it safe to store secrets in environment variables in Docker containers? A: Environment variables in Docker are better than hardcoded strings, but they’re still visible in docker inspect output and process listings. For production, use Docker Swarm secrets or Kubernetes Secrets (ideally with external-secrets-operator pointing to Vault or AWS Secrets Manager) to avoid exposing secrets in the container config.

Q: How often should a startup rotate its API keys and database passwords? A: At minimum, rotate secrets when a team member leaves, when you suspect a breach, and on a regular schedule — I use 90 days for API keys and 30 days for database passwords in production. AWS Secrets Manager and Vault both support automatic rotation, so there’s no excuse not to automate it.

Q: What should I do if I accidentally push a secret to a public GitHub repository? A: Act immediately. Revoke and rotate the secret first — assume it’s already compromised. Then remove it from git history using git filter-repo --path .env --invert-paths. Finally, audit your cloud provider’s logs (CloudTrail, GCP Audit Logs) for unauthorized activity in the 15–30 minutes after the push.

Conclusion

Secret management isn’t glamorous, but it’s one of the highest-ROI security investments a startup can make. I’ve seen $50K AWS bills, regulatory nightmares, and customer trust destroyed — all because of a leaked credential. Spend one afternoon setting this up properly, and you won’t have that story to tell.

About the Author

I’m a senior software engineer and DevOps practitioner with 12 years of experience building and securing production systems at startups and Fortune 500 companies. My primary stack is Node.js, Python, AWS, and Kubernetes — I’ve helped over 20 early-stage teams establish secure infrastructure from zero to Series A. If you have questions about this article, reach out on LinkedIn or leave a comment below.