Secrets Management for Developers and Small Teams

What counts as a secret

A secret is any value that grants access: database passwords, API keys for payment gateways and email services, cloud access keys, signing keys for tokens, webhook signing secrets, SSH keys and encryption keys. If someone who obtained the value could read data, spend money or impersonate your system, it is a secret. Make a list of every secret your application uses, where it is stored, who can access it and when it was last changed.

Secrets leak in predictable ways. They are committed to Git and pushed to a public repository, pasted into chat messages or tickets, printed in logs, bundled into frontend JavaScript or mobile apps, or left in old backups and screenshots. Automated bots scan public repositories constantly, so a key pushed by mistake can be found and misused very quickly. Prevention is far easier than cleanup.

Keeping secrets out of code

Never write secrets in source code or commit them to version control, even in private repositories. Load them at runtime from environment variables or a secrets manager. Keep local development values in a file that Git ignores, and commit only an example file that lists the variable names with placeholder values. Make the application check for required settings at startup and stop with a clear message if any are missing, as shown below.

# Illustrative Python: read secrets from the environment
# and fail fast at startup if any are missing.
import os
import sys

REQUIRED = ["DATABASE_URL", "PAYMENT_API_KEY", "SESSION_SECRET"]

def load_config() -> dict:
    missing = [name for name in REQUIRED if os.environ.get(name) is None]
    if missing:
        # Log the names only, never the values
        sys.exit("Missing required settings: " + ", ".join(missing))
    return {name: os.environ[name] for name in REQUIRED}

config = load_config()

Where to store secrets

For production, use a dedicated secrets manager where possible. Major cloud providers offer one, and tools such as HashiCorp Vault, Doppler or Infisical work across platforms. These services encrypt secrets, control who can read them, record access in audit logs and support rotation. Platform settings on hosting services and CI systems also provide encrypted secret storage that is far safer than files on a server.

Apply least privilege. Each service should have its own credentials with only the permissions it needs. A reporting job needs read access to some tables, not full database administrator rights. Separate credentials for development, staging and production, so a leaked development key cannot touch real customer data. Limit which team members can view production secrets, and remove access promptly when someone leaves the team or a contractor's engagement ends.

• One set of credentials per service and environment
• Read access only where writes are not needed
• Production secrets visible to as few people as possible
• Access reviewed when people join, change role or leave

Scanning, rotation and leaks

Add secret scanning to your workflow. Tools such as Gitleaks or TruffleHog can run as a pre-commit hook and in CI, and many code hosting platforms offer built-in secret scanning and push protection. These catch most accidental commits before they become incidents. Run a scan across your full Git history once, because old commits can still contain keys that were later removed from the current code.

If a secret leaks, rotate it immediately: create a new value, deploy it and revoke the old one. Deleting the commit is not enough, because copies may already exist. Then check the provider's logs for misuse during the exposure window. Practise rotation before you need it, so you know each step works. XDQ Labs teams record the rotation steps for each secret in a short runbook, which turns a stressful leak into a routine task.

Check your understanding