On this page
A one-person business has the same secrets as a company — payment keys, a mail API, a database, a registrar login — and none of the process around them. There is nobody to review the commit and nobody to notice the file. The good news is that four of the five common leaks close in about ten minutes, and the fifth is a habit rather than a tool.
I rotated a leaked token on this project last month. Everything below is the version of this I would have wanted written down.
Where do keys actually leak from?
| Route | How it usually happens |
|---|---|
| Committed to a repository | a config file added before .gitignore existed |
| Pasted into a chat or an issue | debugging with someone, or with a model |
| Shipped in frontend code | a build-time variable exposed to the client |
| Captured in a screenshot or recording | a terminal, a dashboard, an editor sidebar |
| Served as a static file | a .env or a backup inside the published directory |
None of these are sophisticated. All of them are things you do while concentrating on something else, which is exactly why a process beats vigilance.
What closes most of it quickly?
Put secrets in the host's environment variables, not in files. The deployment platform has somewhere to store these. Use it, and keep the local .env out of version control from the first commit rather than the second.
Have a deny list for what gets published. A static site deploys a directory, and a directory contains more than you think — notes, backups, build scripts, the odd CSV. An explicit ignore file for the deploy is the difference between publishing a site and publishing a folder.
Check what a stranger can actually fetch. Request the paths that should not exist and look at the status code. What can a stranger read is a prompt for working through this properly.
Search your built output, not your source. grep the directory you deploy for the first eight characters of each live key. Source code being clean is not the same as the build being clean.
The whole list
67 tools, what each costs and when you actually need it. Updated twice a year.
Which secrets are the dangerous ones?
Not the ones people worry about.
| Secret | If it leaks |
|---|---|
| Analytics or read-only key | noise, little else |
| Mail API key | someone sends mail as you — reputation damage that outlives the key |
| Payment secret key | refunds, payouts, customer data |
| Database service key | everything, including bypassing your own access rules |
| Registrar or DNS login | your domain, your email, and the ability to prove you are you |
The last row is the one with no undo. Everything above it is rotatable in minutes; a domain taken out from under you is a different kind of week. That account deserves a unique password, hardware or app-based two-factor, and recovery details that are current.
This is the actual argument for a password manager in a business of one: not the forty site logins, but the five accounts where losing access is unrecoverable and nobody else has a copy.
What do you do when one leaks?
Rotate first. Investigate afterwards.
A revoked key is harmless no matter who has it, and the investigation is much calmer once that is true. The instinct to first work out whether anyone actually saw it has the order backwards — that question takes an hour and the rotation takes two minutes.
Three things that are not fixes:
- Removing the commit. Assume anything pushed to a remote is permanent. It is in forks, caches and clones you do not control.
- Rotating only the one you noticed. If a file leaked, every key in that file leaked.
- Deciding it was probably fine. This is the only one on the list that will cost you money.
What about keys you give to an AI agent?
Same rules, with one addition: an agent reads files you did not point it at.
A coding agent working in your project will open configuration, environment files and anything else in the directory while establishing context. That is what makes it useful. It also means "the key is only in a local file" stops being a meaningful boundary.
Keep secrets in the host's environment rather than in the working directory where you can, and treat anything in the project folder as something the agent — and therefore the transcript — has plausibly seen. How to brief an AI agent once covers setting boundaries that hold across sessions.
What is the ten-minute version?
If you do nothing else:
- Confirm your local secrets file is in
.gitignore, and that it was there before the first commit. - Confirm your deploy has an ignore list, and that requesting your secrets file on the live site returns a 404.
- Move every live key from a file into the host's environment settings.
- Turn on two-factor on the registrar, the payment account and the mail provider.
- Put the recovery codes for those three somewhere that is not the laptop they protect.
Four of those are one-time. The fifth is the one people skip and the one that matters at 2am.
Where to go deeper
Find exposed secrets is the prompt for auditing an existing project, and is your AI-written app safe to put online? covers the wider version of this question for something you are about to launch.
Claude Code Operator is the one that covers working with an agent on a real codebase, including what you let it see.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| 1Password | Password manager. Also where client credentials belong. | ~€3–5/mo |
| GitHub | Version control. Your restore point when an hour of building goes wrong. | Free |
| Vercel | Hosting. Puts a project live on a real address with one command. | Free tier |
| Supabase | Database, accounts and file storage in one, with no backend work. | Free tier |
| Stripe | Payments and subscriptions. The standard, and integrating it is a matter of asking. | Free, percentage per sale |
| Cloudflare | DNS, domains and basic protection. | Free |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
Where do API keys actually leak from?
Five places, in rough order of frequency: committed to a repository, pasted into a chat or an issue, embedded in frontend code that ships to the browser, left in a screenshot or a screen recording, and stored in a file that a web server will happily serve.
Is it safe to put a key in an environment variable?
On the server, yes — that is what they are for. In a frontend build, no. Anything the browser receives is readable, and a build-time variable prefixed for client use is published, not hidden.
What should you do when a key leaks?
Rotate it first, investigate second. A revoked key cannot be used regardless of who saw it, and the investigation is much calmer once that is true. Removing the commit does not help — assume anything pushed is permanent.
Do you need a password manager for a one-person business?
Yes, and less for passwords than for the shared secrets with no owner: the domain registrar, the payment account, the DNS. These are the ones that are catastrophic to lose and that nobody will remind you about.
How do you check whether a secret is exposed?
Request the file directly in a browser and see what comes back, search your built output for the key string, and open the network tab on your own site. All three take minutes and catch most of it.