In the code column — .env.example. Notice: the whole security lesson is in its comments. That's no accident — it's where a future developer will read it.

The .env workflow:

cp .env.example .env      # copy the template
# ...put your key in .env...
# .env is .gitignore'd — it never reaches git

Verify — and this is the most important action in the lesson. Build and find the key in the bundle:

npm run build
grep -r "VITE_NASA_API_KEY\|DEMO_KEY" dist/assets/
# → dist/assets/index-a1b2c3.js:  ...api_key=DEMO_KEY...

Your key is in plaintext in a production file you serve to the whole world. Anyone who opens DevTools → Network or Sources will see it. There's no way to "hide" it in front-end code — because the browser has to run that code, which means it has to read it.

When it's fine, when it isn't:

Key	OK in front-end?
NASA APOD (public, rate-limited)	Yes — that's what it's for
Stripe publishable key (pk_...)	Yes — public by design
Stripe secret key (sk_...)	NEVER — on the server
DB password, a mail API key	NEVER — on the server

Deploy. You upload dist/ to a static host. Env vars are set in the host's dashboard (not the .env file, which stayed local).

Gotcha (a secret in .env is NOT hidden). A common mistake: "I'll put the secret key in .env — .env isn't in git, so it's safe." No. .gitignore hides the key from git, but Vite still inlines it into the bundle via import.meta.env.VITE_.... .env protects against an accidental commit, not against the bundle. The only way to keep a key secret is to never send it to the browser: keep it on a server that proxies the request.