Separate API keys for staging and production: a checklist

Most teams treat API keys as an afterthought until a staging experiment blows up the production bill. Proper staging vs production API key separation is the cheapest insurance you can buy against credential leakage, runaway costs, and noisy-neighbor incidents that take down real users.

1. Generate independent keys for each environment

Never reuse the same token across environments. A single key shared between staging and production means a leak in a throwaway test harness instantly compromises live traffic. Generate a dedicated key per environment from your provider’s console or admin API.

# Create a staging key via provider CLI (illustrative)
provider keys create --name "staging" --env staging
provider keys create --name "production" --env prod

Store the returned secrets immediately in your secret store; the provider will only show them once. If you later need to distinguish traffic at the gateway level, a separate key is also the cleanest way to apply different routing or cache policies without code changes.

2. Restrict key permissions and scopes

Production keys should carry the minimum scopes necessary for the live path. Staging keys can have broader scopes for experimentation, but still avoid admin privileges. If your provider supports resource policies, attach them directly to the key.

{
  "key_id": "sk-staging-abc",
  "scopes": ["completions:write", "embeddings:write"],
  "allowed_models": ["gpt-4o-mini", "claude-3-haiku"],
  "deny": ["billing:read", "keys:admin"]
}

This prevents a staging script from accidentally calling an expensive model or reading account metadata. The same policy pattern applies to any LLM gateway: lock the key, not just the code. A narrowly scoped staging key can be handed to interns without sleepless nights.

3. Use secret managers, never hardcode

Hardcoding keys in a .env committed to git is how most breaches start. Use a real secret manager (AWS Secrets Manager, GCP Secret Manager, Vault) and inject at runtime. Your app should read from an environment variable that the orchestrator populates.

import os
from vault_client import Vault

v = Vault(os.environ["VAULT_ADDR"], os.environ["VAULT_TOKEN"])
secret = v.read(f"secret/{os.environ['APP_ENV']}/llm_key")
os.environ["OPENAI_API_KEY"] = secret["value"]

In staging, APP_ENV=staging pulls the staging key; in production it pulls the prod key. No developer laptop ever needs the production value. Rotate the secret in the manager and the next deploy picks it up without a code change.

4. Enforce separate rate limits and quotas

Staging traffic is unpredictable: someone runs a load test, a notebook loops, a CI job spawns 50 workers. If staging shares production’s quota, you get 429s on real requests. Set per-key rate limits at the provider or gateway.

# Example limit call (illustrative)
provider limits set --key sk-staging-abc --rpm 100 --tpm 50000
provider limits set --key sk-prod-xyz --rpm 2000 --tpm 2000000

When a provider offers automatic fallback on degradation, separate keys ensure the fallback pool for production isn’t exhausted by staging retries. That isolation is a core reason staging vs production API key separation matters under incident conditions.

5. Monitor usage per key with metering

You cannot manage what you cannot measure. Per-key usage metering lets you spot a staging job that suddenly consumes 80% of your monthly budget. Export metrics to your observability stack and alert on anomalies.

// Pseudo-middleware logging per-key token usage
app.use(async (req, res, next) => {
  const key = req.headers["authorization"]?.split(" ")[1];
  const start = Date.now();
  await next();
  metrics.histogram("llm_tokens", res.locals.tokenCount, { key, env: process.env.APP_ENV });
});

If you route LLM traffic through a gateway such as n4n.ai, per-token usage metering lets you attribute spend to each isolated key without standing up separate billing accounts. This turns a compliance headache into a dashboard query.

6. Rotate keys on a schedule and on offboarding

Keys leak. Employees leave. A quarterly rotation limits blast radius. Automate rotation so it’s not a manual Jira ticket. Keep the old key active for a short overlap to avoid downtime.

# Rotate staging key, keep old for 24h
OLD=$(provider keys rotate --key sk-staging-abc --grace 24h)
echo "Staging old key $OLD valid for 24h"

Update the secret store and deploy before the grace period ends. Production rotations should happen during low-traffic windows and always with a tested rollback. Staging vs production API key separation means a failed rotation in staging never becomes a SEV1.

7. Isolate data and logging contexts

A staging key should never point at production datasets, and logs should tag which key (thus which environment) made a call. This makes debugging traceable and prevents PII from staging tests leaking into prod logs via shared sinks.

{
  "log_config": {
    "include_key_id": true,
    "redact_prompts_in": "staging",
    "redact_prompts_in_prod": false
  }
}

Staging vs production API key separation also simplifies compliance: auditors can see that test traffic uses synthetic data because the key scope forbids real user stores. The log tag alone is often enough to satisfy a reviewer.

8. Automate key provisioning in CI/CD

Don’t manually create keys for each new service. Use Terraform or a bootstrap script in your pipeline so every environment gets its key from the same module. This removes drift between what devs run locally and what ships.

resource "provider_key" "staging" {
  name   = "svc-staging"
  env    = "staging"
  scopes = ["completions:write"]
}

Running terraform apply in the staging workspace creates only the staging key; the prod workspace creates the prod key. The separation is encoded in infrastructure, not in someone’s memory. Review the plan like any other code change.

9. Test fallback and revocation procedures

A key is only as good as your ability to kill it. Quarterly, revoke the staging key and confirm systems fail safe (use backup key or alert). If you rely on provider fallback, verify staging degradation doesn’t trigger production reroutes because of shared credentials.

provider keys revoke --key sk-staging-abc --force
# Expect staging CI to fail loudly, prod unaffected

Document the revocation runbook. The time to learn your staging key is hardcoded in a lambda is during a drill, not during a breach. Separate keys make the blast radius of a revocation trivially small.

10. Audit and document ownership

Every key needs a owner, a purpose, and an expiry. Use a simple registry (even a README) that lists key ID, environment, owner slack, and last rotated date. Orphaned keys are the most common cleanup gap.

Good staging vs production API key separation is not a one-time setup; it’s a habit reinforced by audits. Delete keys for services that no longer exist.

Synthesis

Treat keys like production code: versioned, scoped, monitored, and isolated by environment. The checklist above reduces blast radius and makes incidents boring. Start with independent keys and secret management, then layer on quotas, metering, and automation until the separation is invisible infrastructure.