Skip to content

API Keys & Secrets

Jesse edited this page Nov 30, 2025 · 2 revisions

API Keys & Secrets

API keys, private tokens, and service credentials must never be committed to any repository β€” public or private.
Leaking a key can expose systems, incur billing charges, or compromise client data.

This page explains how to properly manage secrets using environment variables, secure .env files, and safe rotation practices.


🚫 Never Commit Secrets Into a Repository

Why this rule exists

Even if a repo is private, you must assume it could become exposed.
Secrets committed into Git history are permanently retrievable, even after deletion.

Risks include:

  • Unauthorized access to external APIs
  • Financial cost for abused tokens
  • Security responsibility for leaked client data
  • Public exposure if the repo is ever made open-source

If a secret is committed, you MUST rotate it immediately.


Use Environment Variables

How to store credentials with environment variables

Environment variables keep secrets separate from your codebase.

Examples of environment-based access:

API_KEY=abcd1234
AUTH_TOKEN=somerandomvalue

Then access it in code:

const apiKey = process.env.API_KEY

Best Practices

  • Use .env files locally
  • Read values using process.env.VARIABLE_NAME
  • Never hardcode strings like apiKey = "12345"
  • Document what environment variables are required

Store .env Files Securely

Rules for handling .env files

.env files contain secrets β€” treat them like passwords.

Storage Requirements

  • Always add .env to .gitignore
  • Do not upload .env to GitHub
  • Do not send .env in Slack/Discord/Email
  • Store .env files locally or in secret managers

Example .gitignore entry:

.env
.env.production
.env.development

When collaboration is required

  • Share via secure channels (Bitwarden, 1Password, encrypted file transfer)
  • Never commit for convenience

Manage Secrets During Development

How to work safely without exposing keys

Recommended Workflow

  • Keep personal .env local per developer
  • Use .env.example to show variable names without real values
  • Document required keys in the README or wiki

Example .env.example:

API_KEY=
FIREBASE_PROJECT_ID=
EAS_SECRET_TOKEN=

Developers fill in values privately β€” not stored in repo.

Tips

  • Comment purpose of each variable in .env.example
  • Use different keys for dev and prod environments

Rotate API Keys When Needed

When rotation is required and how to do it safely

API credentials must be rotated (replaced) when:

  • A key is accidentally committed
  • A team member leaves the project
  • A repository is made public
  • A device with secrets is lost
  • Client requests renewal

Rotation Procedure

  1. Generate a new key in provider dashboard
  2. Replace old key in .env or secret manager
  3. Remove any committed references
  4. Notify team to update their .env
  5. Invalidate/delete old key

Never leave old keys active.


Clone this wiki locally