Generating API Keys Safely as a Solo Founder

The one mistake that causes 90% of leaks

Keys get committed to a public Git repo. A bot scrapes it within minutes and your bill is $4,000 by morning. Everything below exists to make that impossible.

What a leaked key actually costs you

It is rarely just the key. A leaked Stripe key means charges on your account and refunds you have to process. A leaked cloud key can spin up mining instances that show up as a five-figure bill. A leaked email provider key means someone sends phishing from your domain, and your deliverability dies for months. The cost is almost never the key itself — it is the cleanup, the chargebacks, and the lost trust.

The .gitignore safety net

Before your very first commit, add the files that hold secrets to .gitignore. This is the cheapest insurance in software:

# .gitignore
.env
.env.*
secrets.json
*.key
credentials/

If a secret was committed by accident, deleting it from the latest commit is not enough — it stays in history. Use a tool like git filter-repo to purge it, then rotate the key anyway.

Using env vars the right way

Env vars keep secrets out of source code. In most stacks you read them at runtime:

// Node.js
const key = process.env.STRIPE_SECRET_KEY;
// Python
import os
key = os.environ["STRIPE_SECRET_KEY"]

Never log the value, never echo it in a build step you cannot see, and never print it to the browser console. The moment a secret hits a log file, treat it as burned and rotate it.

1. Generate locally, never in a chat window

Don't ask an AI assistant to "make me a key" and paste it into Slack. Generate it on your own machine so it never touches another system. Glint AI's Password & Key Generator runs entirely in your browser — the key is created on your device and never uploaded.

# Example: a strong key has length + mixed classes
sk_live_8Kf2$mPq9wLx!3RtYbNcA1dE7hUvZ

2. Store, don't scatter

• Use a password manager (1Password, Bitwarden) as your key vault. One place, encrypted.
• Use env vars in code: read keys from the environment, never hardcode them.
• Add a .gitignore rule for .env before your first commit.

# .env  (never commit this file)
STRIPE_SECRET_KEY=sk_live_...

3. Scope every key to the minimum

If a key only needs read access, don't grant write. If it only needs one service, don't grant the whole account. Most providers let you set scopes or create restricted keys — use that, even when it's one extra click.

4. Rotate on a schedule

Set a calendar reminder: rotate keys every 90 days, and immediately on any suspicion of exposure. Keep the old key active for 24 hours during rotation so nothing breaks, then revoke.

5. Separate environments

Never use a production key in local development or in a demo video. Maintain at least:

• dev — fake or low-limit keys
• staging — mirror of prod, separate key
• prod — the only key that touches real money/data

Third-party services and shared secrets

Your risk is not only your own keys. Every integration you connect (analytics, email, payments) holds a secret too. When a vendor asks for your key, ask: can they scope it? Do they store it encrypted? Can you revoke it without breaking the integration? The safest setups use short-lived tokens or OAuth instead of long-lived keys you cannot see expire.

How to revoke and recover

When you suspect a leak, the order matters:

1. Revoke the key now. Stop the bleeding before analysis.
2. Check recent activity for charges, sends, or reads you didn't make.
3. Issue a new scoped key and update only the places that need it.
4. Document what happened so the same gap doesn't reopen.

A simple key inventory

Future you will forget where each key lives. Keep a one-line note per key (stored in your password manager, never in the repo):

STRIPE_SECRET_KEY  | prod | rotates 2026-11-01 | used by: checkout
MAILGUN_KEY        | prod | rotates 2026-12-15 | used by: transactional

A note on mobile and shared machines

Most leaks happen on the laptop you travel with. Enable disk encryption (FileVault on Mac, BitLocker on Windows) so a stolen machine doesn't hand over every local key. On a shared or borrowed computer, never paste a production key into a browser tab you can't fully close — use a temporary restricted key instead, and revoke it the moment you're done. The rule is simple: the more exposed the device, the more restricted the key it's allowed to hold. A borrowed machine is never trusted with prod.

A 2-minute solo-founder routine

1. Generate the key in a local tool (not in chat).
2. Paste it only into your password manager and your .env.
3. Confirm .env is gitignored.
4. Set a 90-day rotation reminder.
5. Write down where it's used — future you will forget.

FAQ

Is a browser-based generator safe? Yes, if it runs fully client-side and shows the key only on your screen. Nothing is sent to a server. Verify the tool's privacy claim before trusting it.

How long should a key be? 32+ characters with mixed classes is a solid baseline for secret keys.

Should I encrypt .env? For a solo founder, gitignoring it and storing it in your password manager is enough. Encrypt if the machine is shared.