Skip to main content
Stackbastion

Draft, not yet published

Environment parity: why your AI-generated app behaves differently in production

7 July 2026· 5 min read · by Stackbastion

The classic bug report you file against yourself: “works on my machine.” The signup flow is perfect in local testing, then a real user hits it in production and gets a blank page or a 500. Nothing in your code changed. What changed is everything around your code, the settings and services that differ between your laptop and the server.

Why this happens

“Environment parity” means your development, staging, and production setups behave the same way. When they drift apart, bugs appear only in the environment you can’t easily poke at, which is always production.

AI tools make this worse without meaning to. They generate code that assumes your laptop’s setup: a local database with no password, no HTTPS, error messages printed to the screen, a permissive CORS policy that accepts every origin. That’s fine locally. In production the database has a password and runs behind a connection pooler, HTTPS is on, and your API sits on a different domain than your frontend. The code that worked now hits conditions it never saw.

Here’s a concrete one. Your generated code builds a URL like this:

// Works locally, breaks live
const apiUrl = "http://localhost:3000/api";
fetch(`${apiUrl}/users`);

On your laptop, localhost:3000 is your backend. In production, localhost means the user’s own device, which has nothing running on port 3000. So every API call fails with a connection error, and you get a blank page. The code is identical. The environment isn’t.

Other common mismatches:

  • Database URL hardcoded to your local one, so production either can’t connect or, worse, quietly reads and writes your dev data.
  • CORS wide open (origin: "*") locally, then either still wide open in production (a security hole) or suddenly locked down and blocking your own frontend.
  • Debug mode on, so production leaks stack traces and secrets to anyone who triggers an error.
  • A missing env var that defaults to something harmless locally and something broken live.

The root cause is always the same: a value that should come from configuration got baked into the code instead.

How to fix it

The rule is simple. Anything that differs between environments must come from an environment variable, not a literal in the code. Then each environment supplies its own values, and the code itself stays identical everywhere.

Step 1: pull the differences out into env vars

// Before: baked in, breaks when the environment changes
const apiUrl = "http://localhost:3000/api";

// After: the environment decides
const apiUrl = process.env.PUBLIC_API_URL;
if (!apiUrl) throw new Error("PUBLIC_API_URL is not set");

That guard clause matters. If the variable is missing, fail loudly at startup instead of limping along with undefined and producing a confusing error three screens later.

Step 2: validate all your config in one place, at boot

Don’t scatter process.env.X reads across 40 files. Read and check them once, at startup, and fail fast if anything’s wrong or missing. This is a good place for Zod:

import { z } from "zod";

const Env = z.object({
  NODE_ENV: z.enum(["development", "staging", "production"]),
  DATABASE_URL: z.string().url(),
  PUBLIC_API_URL: z.string().url(),
  CORS_ORIGIN: z.string().url(),
  STRIPE_SECRET_KEY: z.string().min(1),
});

// Throws with a clear message if anything is missing or malformed
export const env = Env.parse(process.env);

Now a missing DATABASE_URL stops the app at boot with “DATABASE_URL required,” not a mystery timeout in the middle of a checkout.

Step 3: keep an .env.example in the repo

Commit a template listing every variable the app needs, with dummy values. Never commit the real .env. This is the one document that tells the next person (or the next you) exactly what each environment must provide:

# .env.example: copy to .env and fill in per environment
NODE_ENV=development
DATABASE_URL=postgres://user:pass@localhost:5432/app
PUBLIC_API_URL=http://localhost:3000/api
CORS_ORIGIN=http://localhost:5173
STRIPE_SECRET_KEY=sk_test_xxx

Add .env to .gitignore. If the real file is already committed, remove it and rotate any secret that was in it, because it’s now in your git history forever.

Step 4: make the environments as alike as you can

Parity isn’t only about variables. Run the same Postgres version locally that you run in production, ideally in Docker so it’s one command to match:

# Same major version as production, so you catch version-specific bugs locally
docker run --name app-db -e POSTGRES_PASSWORD=devpass -p 5432:5432 -d postgres:17

Turn HTTPS on in a staging environment too, so certificate and cookie behavior gets tested before real users see it. The closer staging is to production, the fewer surprises production hands you. For why a staging environment earns its keep and how to stand one up cheaply, see why your AI-generated app needs a staging environment.

Or, we do it for you

Config validation, proper secret handling, and matched environments are part of every production setup we run. If your app “works locally but breaks live” and you’re not sure why, get a free audit and we’ll find the mismatches.

FAQ

Why not just hardcode the production values once I know them?

Because then dev and production run different code, and the difference is invisible until it bites. It also tends to put secrets in your source. Configuration in env vars keeps one codebase behaving predictably in every environment. It’s less work over time, not more.

What’s the difference between staging and production?

Production is what real users touch. Staging is a near-identical copy where you test changes first, with fake data and real settings. Staging exists to catch parity bugs before your users do. It should mirror production as closely as your budget allows.

I found my real .env in git. What now?

Rotate every secret in it right away: database passwords, API keys, tokens. Assume they’re compromised, because git history is easy to read. Then remove the file from the repo and add it to .gitignore. Deleting the file in a new commit isn’t enough on its own; the old values still live in history.

How do I know which values differ between environments?

Search your code for anything hardcoded: localhost, IP addresses, http://, database strings, API keys. Each one is a candidate to move into an env var. If a value would be wrong on the server, it belongs in configuration.

Related posts