Sponsored by Hostinger. Affiliate links may earn a commission at no extra cost to you. Details.

Back to Security

Per-Environment Keys (Dev / Staging / Prod): The Simplest Setup

Most solo builders use one API key for everything. Local development. Staging tests. Production. Same key, three environments. It's simple. It's also how you accidentally burn through your monthly OpenAI budget on a test loop you forgot to break out of.

The fix is per-environment keys. The setup is simpler than you'd think.

Why one key is a problem

When dev, staging, and prod all share a key, you can't tell from the OpenAI dashboard who's burning what. A spike at 2am could be a runaway dev loop, a staging stress test, or a real production surge. You can't tell. You also can't cap one environment without capping all of them — set a $200/month limit and your prod traffic might hit the wall first, with no buffer.

Start with IBYOK

Free tier — 250 calls/month, no card required.

And if you ever need to rotate (because the dev key got committed to a public repo, say), you have to rotate everywhere. Every environment goes down at once until you've updated them all.

The fix

Three keys, one per environment. Each key has its own monthly cap. Each key shows up separately in the dashboard. Each can be rotated independently.

Naming convention I use:
OPENAI_KEY_DEV — local development, capped at $20/month
OPENAI_KEY_STAGING — staging tests, capped at $50/month
OPENAI_KEY_PROD — production, capped at whatever you actually need

The dev cap is intentionally tiny. If a dev loop runs away while you're asleep, $20 is the worst case. You'd notice the failure when the cap hit, fix the loop, and move on without the heart attack.

How to issue them

If you're working straight from the OpenAI dashboard, create three separate keys, label them, save the caps, and store them per environment. That works.

If you're using a vault (IBYOK in my case), it's cleaner: one underlying OpenAI key, three vault-issued credentials each scoped to a single environment with its own cap. Same effect, single source of truth, easier to rotate.

Pointing each environment at the right key

Local: in your .env.local (which is gitignored), set OPENAI_API_KEY to your dev key. Done.

Staging: set the env var in your staging deployment platform (Vercel, Render, your VPS, wherever) to your staging key.

Prod: same, with the prod key.

Your code reads OPENAI_API_KEY in all three environments, but it gets a different actual key depending on where it's running. The code doesn't change. The environment provides the right credential.

The peace of mind

The first time you set this up it feels like overhead. After the first runaway test loop you ever have, it feels like the smartest 20 minutes you ever spent. The cap on dev catches the loop before it costs real money. The dashboard shows you which environment had the issue. Rotation is local to the affected environment.

If you do nothing else for AI security this month, do this. Three keys. Three caps. One Friday afternoon. Never share your prod budget with a dev typo again.

— Jeff

Start with IBYOK

Free tier — 250 calls/month, no card required.