Builder Toolkit · 05 / 11

Gitignore and Secrets

Know what must never be committed, set up .gitignore correctly, and recover safely if a key leaks.

Gitignore and Secrets

What this is

A secret is any value that proves you are you: an API key, a database password, an access token.

.gitignore is a plain text file listing what Git should never record. Anything named in it stays on your machine.

The one idea

Public repositories are readable by anyone, and Git remembers everything. A key pushed once is exposed even after you delete it.

Why it matters

Automated scanners watch public GitHub commits for key patterns. A leaked key can be found in minutes, not months.

The consequences are real: someone else spending your AI credits, reading your database, or sending email as you. This page takes five minutes and prevents the most expensive beginner mistake in the whole toolkit.

What to do

Know what never gets committed

Never commit	Why
`.env`, `.env.local`	These files exist specifically to hold secrets.
API keys and tokens	They authorise spending and data access.
Database passwords	They open your whole database.
Service role keys	They bypass every access rule.
`node_modules`	Not secret, just enormous and rebuildable.

Set up .gitignore before your first push

Create a file named exactly .gitignore in the project root. The leading dot is part of the name.

Copy

node_modules
.env
.env.local
.env.*.local
.DS_Store

Most starter projects, including the KDBM Lite starter, already include one. Check before adding your own.

Do this now

Run git status in your project. If you see .env, .env.local, or node_modules in the list, stop. They are not ignored yet. Fix .gitignore before you commit.

Check yourself

My project has a .gitignore file in its root folder.
git status does not list .env or .env.local.
git status does not list node_modules.
I can name at least three things that must never be committed.

Understand the trap

.gitignore only prevents future commits of a file. It does nothing about a file Git is already tracking.

If you added .env.local before creating .gitignore, Git keeps tracking it and ignoring the rule. Stop tracking it with:

Terminal command

git rm --cached .env.local

Swipe sideways if a command is long.

The file stays on your computer. Git stops recording it. Commit that change, and future pushes are clean.

If a key has already been pushed

Do these in order. Do not skip the first one.

Rotate the key immediately. Go to the provider and generate a new one. The old value must stop working. This is the only step that actually protects you.
Update the key everywhere you use it: your local .env.local and your hosting settings.
Remove the file from tracking with git rm --cached, then commit and push.
Assume the old value is public forever.

Deleting is not fixing

Deleting the file in a later commit does not remove it from history. Anyone can read the earlier commit. Rotation is what makes the leaked value worthless.

If you are not sure whether a key leaked

Treat it as leaked and rotate it. Rotating a safe key costs you two minutes. Not rotating a leaked one can cost a lot more.

Common mistakes

Creating .gitignore after the first commit, then assuming past commits are covered.
Naming the file gitignore without the leading dot, so Git ignores the file about ignoring files.
Pasting a real key into a public prompt, a screenshot, or a class chat.
Deleting a leaked key from the repo but never rotating it.
Putting a service role key in frontend code because it made an error go away.

Next step

Your secrets are safe locally. Now get the project online with Vercel Basics.