Module 2 · Where tools live: saving, hosting & staying safe
Keys & secrets: the one safety rule
There’s exactly one safety rule in this whole course, and it’s the title of this lesson: secrets never go in code, and never go to GitHub. Learn it once and you’ll never trip over it.
What a “secret” is
Some tools use paid outside services — a mapping service, an email-sending service, or an AI service itself. To use one, your tool needs an API key: a long password that proves your tool is allowed to use that service (and, usually, that bills you for it). That key is the secret. Treat it exactly like the password to your bank.
The rule, and where secrets actually go
A secret must never be typed directly into your tool’s code, and must never be sent up to GitHub — because a key sitting in code is a key anyone who sees that code can use, on your bill. Instead, secrets live in a special file called .env: a plain file that holds your keys, kept on your computer only. Git is told to ignore that file, so it never gets pushed to GitHub with the rest of your work.
You don’t manage any of this by hand. You just give Claude one standing instruction the moment a key enters a project:
Say this whenever a key enters a project
Put this key in a .env file, make sure it's git-ignored, and never print it.
That’s the entire discipline. Key goes in .env, .env gets ignored by Git, the key never leaves your machine.
Where a key lives
- A .env file on your computer
- Git told to ignore it
- Never leaves your machine
Where a key never goes
- Typed into the code
- Pushed to GitHub
- Pasted into a public chat
None of the three practice builds in this course need any API key. They all run entirely on your computer, with no paid outside service. This lesson exists for later — the day your fourth tool wants to send an email or read your calendar, you’ll already know the one rule that keeps you safe.
Keys are free to replace, so a leak is a fixable mistake, not a disaster. If a key ever ends up somewhere it shouldn’t — pasted into a chat, accidentally pushed to GitHub — go to the service that issued it, revoke the old key, and generate a new one. The old one instantly stops working, and you drop the new one into your .env file. Done.
You can say the rule in one breath: secrets go in a git-ignored .env file, never in code, never to GitHub. You know the one line to tell Claude when a key shows up, and you know that if a key ever leaks, you revoke it and make a new one. That’s the whole of staying safe.
Watch this step
Keys and .env files click fast once you see them — this seven-minute explainer covers exactly the one safety rule this lesson is built around. It’s from an independent creator — credited below, so go give them a follow.
.ENV Files Explained in 7 Minutes (for beginners)
More learning resources
Still want another angle? These are hand-picked and vetted to line up with this lesson — from creators and sites worth your time.