Password and Secrets Management Hygiene for Solo Founders and Contractors

When you operate as a solo developer, bad security habits are easy to ignore.

You store production database passwords in an unencrypted .env file on your desktop. You use the same master password across six SaaS dashboards. You paste an OpenAI secret key directly into a client Slack channel to help them test an endpoint.

Everything feels fine—until you hire your first freelance frontend contractor to help you redesign a user dashboard.

Suddenly, you face a dilemma: How do I let them run the application locally without giving them root access to our production Stripe keys and customer database?

Too many founders panic, hand over the entire production .env file, and hope for the best.

A single disgruntled contractor, a compromised laptop, or an accidental git commit to a public repository can result in wiped databases, stolen customer lists, or thousands of dollars in unauthorized cloud compute charges.

Here is the straightforward secrets management protocol every solo founder and independent contractor should adopt.

Rule 1: Never Check .env Files into Version Control

This sounds like basic advice, but accidental git credential leaks happen thousands of times every day.

Ensure your root .gitignore file includes:

.env
.env.local
.env.*.local
*.pem
id_rsa
secrets.json

Always commit a sanitized .env.example file instead:

# .env.example - Safe for Git
DATABASE_URL="postgresql://user:password@localhost:5432/myapp_dev"
STRIPE_SECRET_KEY="sk_test_placeholder"
OPENAI_API_KEY="sk-placeholder"

This provides new collaborators with a clean structural template without exposing live keys.

Rule 2: Separate Production and Development Environments

Never allow contractors to run local development environments connected to your live production database or production API keys.

1. Stripe: Keep test mode completely isolated. Contractors should only ever receive pk_test_ and sk_test_ keys.
2. Database: Use Docker or a local PostgreSQL instance with seeded mock data. If you use cloud databases like Supabase or Neon, create an isolated “Staging/Dev” project populated with dummy user accounts.
3. Third-Party APIs: Generate restricted API keys with strict budget ceilings (e.g., a dedicated OpenAI sub-key capped at $20/month) for contractor testing.

Rule 3: Use a Dedicated Password Vault with Fine-Grained Sharing

Delete spreadsheets, text files, and Slack snippets containing passwords.

Use a modern password manager like 1Password or Bitwarden:

• Create separate vaults: “Personal”, “Startup Core”, and “Contractor Shared”.
• When onboarding a freelancer, share only the specific vault containing their required credentials.
• Use 1Password’s “Masked Email” and single-item sharing links that expire automatically after 24 hours or after a single view.

Rule 4: Zero-Friction Offboarding

When a freelance contract finishes, offboarding should take less than five minutes:

1. Revoke their GitHub repository access.
2. Revoke their shared password manager vault.
3. Rotate any staging API keys or database tokens they had access to.

Because they never touched production secrets, you never have to spend an entire weekend cycling production database strings, regenerating Stripe webhook secrets, or worrying about unauthorized data access.

The Git History Purge: What to Do When a Secret is Accidentally Committed

Even disciplined developers occasionally commit an active secret to a git branch.

If you push an API key or database string to a repository—even a private one:

1. Consider that secret instantly compromised: Do not just delete the line in a new commit and push again. The secret remains permanently readable in your git commit history.
2. Immediately Rotate the Credential: Go to your provider dashboard (OpenAI, Stripe, AWS) and generate a new key immediately, revoking the compromised key. Rotating the key neutralizes the threat in under 60 seconds.
3. Rewrite Local Git History: Use tools like git-filter-repo or BFG Repo-Cleaner to expunge the sensitive string from historical git tree objects before pushing force updates.

Automated Secret Scanning with Pre-Commit Hooks

The best way to prevent accidental credential commits is to stop them before they leave your local workstation.

Install a pre-commit secret detection hook like trufflehog or gitleaks:

# Install gitleaks via Homebrew
brew install gitleaks

# Enable automatic scanning on every git commit
gitleaks protect --staged

Whenever you run git commit, the pre-commit hook scans your staged diffs against known regex patterns for Stripe keys, AWS access tokens, and private RSA keys. If a secret pattern is detected, the commit is aborted immediately, saving you from catastrophic leaks.

Related Operational Guides

For more solo operational security and workflow protection frameworks, read:

• The subcontractor agreement checklist every solo consultant needs
• Why your micro-SaaS database needs row-level security on day one
• Privacy-first analytics: why I replaced Google Analytics