The "Gold Standard" for Securing API Keys on GitHub
To keep your keys safe while maintaining a functional repository, follow this three-layer approach:

1. Local Security: The .env and .gitignore Combo
   Never hardcode keys directly into your source code. Instead, use environment variables.

Create a .env file: Store your keys here locally (e.g., STRIPE_KEY=sk_test_51...).

Update .gitignore: Immediately add .env to your .gitignore file. This tells Git to never track this file, ensuring it never leaves your machine.

Create a .env.example: Commit a template file (e.g., STRIPE_KEY=your_key_here) so other contributors know which variables they need to set up without seeing your actual values.

2. Production Security: GitHub Secrets
   If your project uses GitHub Actions for testing or deployment, you don't need a .env file on GitHub.

Go to your repository Settings > Secrets and variables > Actions.

Add a New repository secret. These are encrypted and can only be accessed by your code at runtime—they are never visible in the clear.

In your workflow YAML, reference them like this: API_KEY: ${{ secrets.MY_API_KEY }}.

3. Safety Nets: Enable Push Protection
   GitHub now offers Push Protection for free on public repositories.

Go to Settings > Code security and analysis.

Ensure Secret scanning and Push protection are enabled.

If you accidentally try to commit a known secret format (like an AWS or Google Cloud key), GitHub will block the push before it reaches the server, saving you from a potential leak.

What if I already committed a key?
[!CAUTION]
Deleting the code is not enough. The secret remains in your Git history.

Revoke/Rotate: Treat the key as compromised. Deactivate it immediately in your provider's dashboard (e.g., OpenAI, AWS).

Scrub History: Use a tool like git-filter-repo or BFG Repo-Cleaner to remove the secret from every past commit in your repository's history.

Force Push: You will need to force-push the cleaned history to GitHub (git push --force).

Never store API keys directly in your code or commit them to a public repo.

The best approach is:

Store them in environment variables

Keep them in a local .env file

Add .env to your .gitignore so it never gets pushed

In production, use your hosting provider’s secret manager (GitHub Actions Secrets, Vercel/Netlify env vars, AWS Secrets Manager, etc.)

Example:

.env

API_KEY=your_secret_key_here

Then access it in your app via environment variables instead of hardcoding it.

This keeps your keys secure and out of version control

The safest pattern is: never commit secrets to Git (even “temporarily”), and load them at runtime from a secure source.

Here are practical options, from simplest to more “production-grade”:

1) Local development: .env file + .gitignore

• Put keys in a local .env file:

  API_KEY=your_key_here

• Add .env to .gitignore so it never gets committed.

• Commit a template instead (so teammates know what to create):

  • .env.example (contains variable names, no real values)

2) In production: environment variables (or platform “secrets”)

Set the key as an environment variable on the host/platform, not in code:

• Docker/Kubernetes: env / secrets
• Vercel/Netlify/Render/Fly/Heroku/AWS/GCP/Azure: use their Secrets / Config Vars UI or CLI
• CI/CD (GitHub Actions, GitLab CI, etc.): store in encrypted repo/org secrets and inject at build/deploy time

3) For stronger security: a secret manager

If this grows beyond a small project, use a dedicated secrets manager:

• AWS Secrets Manager / SSM Parameter Store
• GCP Secret Manager
• Azure Key Vault
• HashiCorp Vault
  These give auditing, rotation, fine-grained access control, and reduced secret sprawl.

4) Defensive best practices

• Limit scope: use least-privilege keys and restrict by IP/domain when possible.
• Rotate keys periodically (and immediately if exposed).
• Prevention: enable secret scanning (GitHub has it) and add a pre-commit secret scanner (e.g., gitleaks).
• If a key ever gets committed: rotate it and consider rewriting history (but rotation is the real fix).

If you tell me what stack/platform you’re using (Node/Python, Vercel/AWS/etc.), I can give the exact steps for that setup.

Never commit API keys to the repo (public or private). Treat them like passwords.

Recommended setup (small project → production):
Local development: environment variables + .env (ignored)

Put secrets in a local file like .env and add it to .gitignore:
.env
.env.*

Commit an example file instead:
.env.example (only placeholders, no real values)
Load env vars at runtime (language-specific loader is fine) and keep the app reading from process.env / os.environ / IConfiguration.

CI/CD: GitHub Actions Secrets
Store secrets in Repo / Environment secrets:
Settings → Secrets and variables → Actions → New repository secret
Inject them into workflows:
env: API_KEY: ${{ secrets.API_KEY }}
Prefer Environment secrets if you have dev/staging/prod separation + required reviewers.

Production: use a secret manager (best practice)
If deploying to cloud/container:
AWS Secrets Manager / SSM Parameter Store
GCP Secret Manager
Azure Key Vault
HashiCorp Vault
App pulls secrets at startup (or via sidecar/agent). Avoid baking secrets into images.

Hardening
Least privilege: scope keys to minimum permissions + IP restrictions if possible.
Rotation: plan key rotation (and automate if supported).
Audit: enable provider logs/alerts for abnormal usage.
Scanning: enable GitHub secret scanning / push protection if available, and add tools like gitleaks in CI.

If a key was ever committed
Revoke/rotate immediately (history rewrite is not enough)
Remove from git history if needed (git filter-repo), but revocation is the real fix.
TL;DR: .env (ignored) for local, GitHub Secrets for CI, and a proper secret manager for production—plus rotation and least privilege.

✅ Best practice

Use environment variables and keep secrets out of Git history.

1. Local development: .env file

Put keys in a .env file:

API_KEY=your_key_here

Add .env to .gitignore so it never gets pushed.

Load it in your app (example Node.js):

import 'dotenv/config';
const apiKey = process.env.API_KEY;
2) CI/CD (GitHub Actions): GitHub Secrets

Repo → Settings → Secrets and variables → Actions

Add a secret like API_KEY

Use it in your workflow:

env:
API_KEY: ${{ secrets.API_KEY }}
3) If the key is used in a frontend

If the key is in browser code, it’s not truly “secret”. Use a backend (or serverless function) to call the API and keep the real key server-side.

4. If you already leaked a key

Revoke/rotate it immediately, then remove it from the repo history (and don’t reuse it).

Select Topic Area

Question

Body

I am working on a small project and I want to keep my API keys secure. What is the best way to store them without exposing them in a public repository?

bro in your project folder create a .env file and keep all the API keys there and then create a .gitignore file and in that keep it like this

Environment variables

.env

and you can able to store them in the public repository without exposing them