Somewhere in setting up your app, you'll end up holding a handful of values that matter more than ordinary settings — a Google Client Secret, a database connection string, maybe an API key for some other service you've connected. Get careless with any of these once, and the fix is rarely as simple as changing a setting. This is the rule both the "Turn on login" section of Your first hour with a template and Configure Google login point back to — and it's short on purpose, because there are really only two rules, and almost every leaked-secret story is someone breaking one of them.

Rule 1: Secrets live in two places, and nowhere else

While you're developing on your own computer, secrets belong in a local file — usually named .env — that your template already reads from automatically. This file sits in your project folder but was never meant to travel with your code.

If your template's backend is ASP.NET Core (the .NET stack these apps are built on), there's an even safer option than .env, and it's the one worth using: user-secrets. Instead of a file sitting in your project folder — protected only by your .gitignore remembering to exclude it — dotnet user-secrets stores the values in a JSON file outside your project entirely, in your own user profile folder, tied to your project by a random ID rather than by location. Set one with a command like:

dotnet user-secrets set "MyService:ApiKey" "sk_your_secret_here"

Your app reads it back exactly the way it reads any other configuration value, so nothing about your code has to know or care where the value actually came from. The advantage is structural, not just habit: because the file never lives inside your repository folder, there's no .gitignore line standing between your secret and an accidental git add . — it's simply not there to be added. It's the local-development equivalent of the "Configuration" panel you'll use once you're live on Azure, and in fact the two use matching key names, so moving a secret from local development to production is just copying the same value into the other place.

Once your app is live, secrets belong in your hosting provider's configuration panel — for these templates, that's Azure's App Service → Configuration → Application settings. Azure stores them securely and hands them to your running app as environment variables, without ever putting them in a file anyone can browse to.

Nowhere else. Not in a component file, not in a comment "just for now," not in a config file you're planning to clean up later. Every secret goes straight into one of those two places and stays there.

Rule 2: Your .gitignore has to actually exclude it

Templates ship with a .gitignore file that already lists .env — meaning Git, the tool that tracks and uploads your code changes, is told to ignore that file completely. As long as you don't rename it, move it, or delete that line, your secrets never get bundled into what you push to GitHub.

The trap is doing something that quietly moves your secret outside that protection: pasting a key directly into a code file "temporarily," or copying .env into a new file with a different name that isn't on the ignore list. Both defeat the entire point.

How to check you haven't already leaked one

This takes two minutes and is worth doing once, especially if you've been experimenting:

  1. Open your repository on GitHub and use its search bar to search your own repo for a fragment of a real key you have — if it shows up in any committed file, it's exposed.
  2. Check your commit history, not just the current files. A secret you added and then "removed" in a later commit is still sitting in your repository's history, visible to anyone who looks — removing it from history requires actively rewriting it, not just deleting the line.
  3. Turn on GitHub's secret scanning (Settings → Code security → Secret scanning, on by default for public repos) — it automatically flags common credential formats it recognizes in your commits.

If you find one

Don't just delete it and move on — a key that was ever pushed, even briefly, should be treated as compromised, because you can't know for certain nobody saw it. Go back to wherever you generated it (Google Cloud Console, for a Google Client Secret) and regenerate it, which invalidates the old value entirely. Then update the new value in your local .env and your Azure Configuration, and redeploy. It's a five-minute fix if you catch it — the cost is only real if it goes unnoticed.

Key Takeaways

  • Secrets live in exactly two places: your local .env file (or dotnet user-secrets for a .NET backend) while developing, and your hosting provider's Configuration settings once live. Nowhere else.
  • Your .gitignore already protects .env — as long as you don't rename it, move it, or paste a secret somewhere else "temporarily."
  • A removed secret can still be in your history. Deleting the line in a new commit doesn't erase it from earlier commits.
  • Turn on GitHub's secret scanning — it's on by default for public repos and catches common credential formats automatically.
  • If a key ever gets exposed, regenerate it. Don't just remove it — treat it as compromised and replace it everywhere it's used.