Development and production should be two different worlds with two different sets of secrets, and in a lot of AI-built apps they are not. The same keys, the same database, the same debug settings get carried straight from your local machine to the live site. It works, so nothing flags it, right up until a dev-only leak becomes a production breach. Keeping the environments separate is cheap insurance against a whole category of that.
Separate keys, because dev leaks
Development is a leakier place than production. Keys get printed to logs, pasted into chats and issues, committed to a test branch, and handed to tools. If your dev and prod keys are the same value, every one of those everyday leaks is a production incident. Give each environment its own keys, and a leaked dev key only affects a throwaway environment you can rotate freely. This pairs with keeping secrets out of code in the first place; see how to stop AI from hardcoding secrets.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →Separate databases, because mistakes happen
Pointing development at the production database means every experiment, seed script, and test runs against real user data, and a slip in dev can corrupt or expose production. Use a separate database for development, with fake or anonymized data. Then a dropped table or a bad migration in dev costs you nothing, and no real user data ever sits in your local environment.
Debug off in production
Debug and verbose error modes are helpful in development and dangerous in production, where they hand attackers your stack traces, file paths, and configuration. Gate them on the environment so production runs with generic errors automatically. Fixes for debug mode in production and the insecure defaults that ship with it.
How to keep them separate
Use per-environment configuration: separate settings for development, preview, and production, each with its own keys and database URL, and never hardcode a value that differs between them. Set production secrets only in your host's environment, not in code, and read debug flags from the environment so production picks the safe settings on its own.
Frequently asked questions
Why not use the same keys in dev and prod?
Because development is a leakier environment. Keys get printed to logs, pasted into chats, committed to test branches, and shared with tools. If your dev and prod keys are the same, every one of those leaks is a production incident. Separate keys mean a leaked dev key only affects a throwaway dev environment, and you can rotate it without touching production. It also lets you revoke access for one without breaking the other.
Should dev and prod share a database?
No. Pointing development at the production database means test code, seed scripts, and experiments run against real user data, and a mistake in dev can corrupt or expose production. Use a separate database for development, ideally with fake or anonymized data. Then a dropped table or a bad migration in dev costs you nothing, and no real user data sits in your local or test environment.
What is the risk of debug mode in production?
Debug and verbose error modes are meant for development, where detailed errors help you. In production they hand attackers a detailed report of your internals: stack traces, file paths, library versions, sometimes configuration. The same setting that is helpful in dev is a disclosure in prod, which is why it must be gated on the environment and off in production.
How do I keep environments separate in practice?
Use per-environment configuration: separate .env files or your host's environment settings for development, preview, and production, each with its own keys and database URL. Never hardcode a value that differs between environments. Set the production secrets only in your host's environment, not in code, and confirm debug flags read from the environment so production runs with the safe settings automatically.
Check what your production app is running
A scan flags a debug flag left on and a secret that shipped where it should not, two of the clearest signs the environments are blurred. Run a free scan and confirm production is running with production settings.