Subscribe

Environment variables, secrets and environments: separating dev, staging and production

Separate dev, staging and production and stop leaking environment variables

Data reviewed on Oct 29, 2026 · LLM Stats indexes and official prices

The data, today

The context

Most configuration incidents look alike: a production database pointed at from staging, a key pasted into a repository, or a variable that exists on your machine and not on the server. None of them is a tool failure; they are separation failures. Each environment should have its own credentials, its own database and, ideally, its own account.

Secrets have a lifecycle: they are created with the minimum permission, live in a manager rather than in code, and are rotated and revoked. When an external platform needs into your cloud, access is granted with a least-privilege role, never an admin key. Here you will find Codifly's guides on each step.

What to decide

  1. 1

    Where do I store secrets?

    In your cloud's or platform's secrets manager, injected at startup; never in the repository or the container image. Locally, use a .env file kept out of Git and an example file with no real values.

  2. 2

    One account per environment, or prefixes?

    Separate accounts give the clearest isolation: a mistake in staging cannot touch production, and permissions are audited per account. If that is too much for your team, start with separate databases and credentials and move to separate accounts as you grow.

  3. 3

    What do I do if a secret leaks?

    Revoke and rotate first, then investigate. Review access logs since the moment of exposure, search for the secret in Git history and application logs, and replace everything that used it. Deleting the commit is not enough: assume someone already copied it.

Common mistakes

  • Sharing one database between staging and production.
  • Handing an external platform an admin key instead of a least-privilege role.
  • Printing full environment variables to application logs.

Tools and comparators

Cloud options comparatorDatabases comparator

Guides to go deeper

Want a recommendation for your case?

Tell us your volume and the options you are weighing. We reply in writing with the numbers of your real usage; no commitment.

Request advice

No provider pays for its position. Indexes come from LLM Stats; prices from each provider's standard API. How we measure

Reduce AI costsMeasure tokens per request and pay for big models only when neededAI customer supportWork out cost per conversation without dropping below your quality barDocument search and RAGFind the right passage before asking the model for an answerCoding with AIMeasure cost per coding task and review what the agent writesCut cloud costsFind the hidden spend in egress, operations and idle resourcesHandle traffic spikesAbsorb traffic bursts without dropping requests or the databaseShip to productionDeploy from Git with separate environments and clean configurationChoose a databaseCompare Supabase, Neon, Turso, PlanetScale and D1 by how they billLaunch an MVPDeploy and store data at minimum cost and without surprisesEvaluate new AI providersCompare Kimi, GLM, Qwen and Muse Spark with the leadersCI/CD from GitHub to productionShip every commit with tests and no long-lived keys in GitHubObservability without surprise billsMeasure what matters with OpenTelemetry and SLOs that don't page anyone for nothingQueues and background jobsProcess heavy tasks without duplicates when something retriesSecure file uploadsReceive files without routing them through your server or blowing up storage costsInfrastructure as codeDecide between Terraform and OpenTofu and keep your infrastructure in GitFast PostgreSQLFind the slow query with EXPLAIN and fix it with the right indexKubernetes or PaaS?Choose where to run your app based on your team, not on fashion
The Codifly brief

A clearer perspective.
In your inbox.

Analysis, guides and new technology comparisons.

You can unsubscribe whenever you like.