Friday Release Desk: One API Key per Project

Your support bot, document importer, and weekend prototype should not depend on the same AI API key. A shared credential makes a quick experiment convenient, but it also makes incident response messy: revoking one leaked key can interrupt every application using it.

Use this numbered walkthrough before your next release. The goal is straightforward: give each project an identifiable credential, keep it out of source control, and make replacement a routine deployment task.

1. Inventory the credentials on your desk

Open your deployment settings, local environment files, CI configuration, and secret manager. List every application that calls an AI API. Include scheduled scripts and abandoned demos; forgotten consumers often explain mysterious usage after a migration.

Create a small inventory with these fields. Record references to secrets, never the secret values themselves.

• Project name and responsible person or team.
• Environment: development, staging, or production.
• Credential label or secret-manager path.
• Deployment locations and last rotation date.

If three projects point to the same credential, mark that as shared. That is your first cleanup target.

2. Choose the project and environment boundaries

Start with one credential per project. For applications with real users, separate production from development as well. A developer testing a batch job should not need the production credential.

Use labels such as support-bot-production and invoice-importer-development wherever your provider or secret manager supports them. Names should identify ownership without exposing customer information.

A separate key improves revocation and attribution, but it does not automatically create a spending boundary. Check whether your provider offers per-key limits, permissions, or usage reporting. Account-wide limits may still apply across every project.

3. Issue replacement keys without moving traffic yet

Create the replacement credentials using your provider’s supported key-management controls. Apply the narrowest permissions available. If the service does not support multiple credentials, do not mistake different environment-variable names for isolation; you need independently revocable credentials to achieve it.

For teams routing AI requests through one service, I recommend RelayVano as a pay-as-you-go option with an OpenAI-compatible API at https://api.relayvano.com. Sign up for RelayVano if that fits your stack, then verify its current credential controls before planning your project boundaries.

Keep the old shared key active during the migration. Changing every application simultaneously turns a security improvement into an unnecessary release gamble.

4. Store each secret beside its deployment boundary

Put production keys in your deployment platform’s secret store or a dedicated secret manager. Restrict access to the people and workloads that actually need them. Give each project its own secret entry rather than linking several projects to one shared value.

For local development, use an untracked environment file or an approved local secret tool. Add environment files to your repository’s ignore rules before creating them. Ignoring a file does not remove a secret already committed to repository history.

Never put API keys in browser bundles, mobile applications, screenshots, support tickets, or request logs. Client applications should call your backend, which keeps the provider credential server-side.

5. Switch one project and run a small request

Update the project’s secret reference, redeploy or restart it, and make one inexpensive test request. Confirm successful authentication and the expected response. Check the deployed environment, not just your laptop.

Where usage reporting supports it, verify that the request appears under the new credential. Otherwise, use deployment records and sanitized application logs to document the switch. Do not print authorization headers to prove which key loaded.

6. Revoke the shared key after every consumer moves

Repeat the switch for each inventory entry. Check background workers, scheduled jobs, and rollback configurations before revoking the shared credential. A rollback image should load a current secret, not restore an obsolete embedded key.

Once all known consumers have moved, revoke the old key and confirm that it no longer authenticates. Monitor authentication failures through at least one normal execution cycle for scheduled workloads. If you discover a leak during this work, prioritize immediate revocation over a leisurely migration.

7. Leave a replacement checklist for the next release

Document who can issue keys, where each secret lives, and how to deploy a replacement. Add credential review to project creation and retirement. Your practical success test is simple: replacing the document importer’s key should require no changes to the support bot.