Dev, Staging, Production: Why You Need All Three

Production Ready — Part 22 of 30

---

It was a Tuesday afternoon when Marcus pushed his payment integration directly to production.

He'd been building solo for three weeks, moving fast. The Stripe integration worked perfectly on localhost — test card approved, webhook fired, database updated. He was proud of it. So he merged to main and deployed.

Forty minutes later, his phone lit up. Real customers were hitting the checkout. And every single payment was failing.

The problem? He'd copied his test environment variables to his .env file, then pushed them straight to production. His live site was running Stripe test keys. No real charges were processing — but Stripe was also silently rejecting every transaction from real cards. Marcus had zero orders, zero revenue, and zero idea why until he dug into the logs.

His staging environment would have caught this in under five minutes. He didn't have one.

This isn't a horror story about a junior dev. This pattern — test something locally, ship directly to production, watch it fail — causes incidents at companies of every size. The 2024 CrowdStrike outage, which took down 8.5 million Windows systems worldwide, was traced in part to a configuration update pushed without adequate staged rollout testing. As the Cloud Security Alliance noted in their post-incident analysis, organizations that kept their latest revision in QA while running production one version behind were better protected — yet even many of them got caught.

The classic Knight Capital disaster — $440 million lost in 45 minutes in 2012 — happened because a deployment failed to update all eight production servers consistently, with no staging environment to catch the mismatch before trading opened.

Three environments. That's the answer. Let's talk about what each one actually does.

---

The Three Environments and Why Each One Exists

Dev: Your Sandbox

Dev is local. It runs on your machine (or a cloud workspace like Codespaces or Replit). This is where you experiment, break things, and figure out how features work.

Key properties of a good dev environment:

• No real data. Use seed scripts with fake users, fake orders, fake everything.
• Test API keys only. Stripe test keys, Twilio test credentials, sandbox everything.
• Fast iteration. Hot reload, verbose logging, mock services where helpful.

Your .env.local file is the gatekeeper here. It should never be committed to git:

# .env.local — never commit this
STRIPE_SECRET_KEY=sk_test_...
DATABASE_URL=postgresql://localhost:5432/myapp_dev
NEXT_PUBLIC_API_URL=http://localhost:3000

The .gitignore entry that protects you:

.env.local
.env*.local

Dev is where you move fast. It's also where you should expect things to break. That's the point.

---

Staging (Vercel Preview): Your Safety Net

Staging is the environment that saves your production. It should be as close to production as possible — same database engine, same environment variable structure, same third-party integrations — but pointed at non-production resources.

In Vercel, staging isn't a separate account or a special tier. It's Preview Deployments — and they're built in.

Here's how Vercel handles this automatically:

• Every push to a non-main branch gets a unique Preview URL
• Every pull request gets a Preview Deployment linked in your PR comments
• Preview environments share your Vercel project but use a separate environment variable scope

To configure separate env vars for preview in Vercel:

1. Go to your Vercel project → Settings → Environment Variables
2. For each variable, choose whether it applies to Production, Preview, or Development
3. Set your staging-specific values under Preview

STRIPE_SECRET_KEY  →  sk_test_...   (Preview)
STRIPE_SECRET_KEY  →  sk_live_...   (Production)

DATABASE_URL  →  postgresql://staging-db-host/myapp_staging  (Preview)
DATABASE_URL  →  postgresql://prod-db-host/myapp_production  (Production)

Your staging Stripe keys process no real money. Your staging database holds no real customer records. When something breaks in staging — and it will — no one gets hurt.

Staging is also where stakeholders do their review. Before you merge a new checkout flow, your product manager clicks through it on the preview URL. Your QA person runs through edge cases. Your client approves the new dashboard design. All of this happens on a URL that looks like https://my-app-git-feature-payments-username.vercel.app — not on myapp.com.

---

Production: Where Real Things Happen

Production is your main branch. It's the environment where real users spend real money and real data gets written to your real database.

The rule is simple: production only receives code that has passed through staging.

Production should have its own isolated environment variables, live API keys, and a production-grade database with backups. In Vercel, production deployments are triggered when you merge to your production branch (by default, main).

Your production environment configuration (set in the Vercel dashboard, never in files):

STRIPE_SECRET_KEY=sk_live_...
DATABASE_URL=postgresql://prod-db-host/myapp_production
NEXT_PUBLIC_API_URL=https://myapp.com

One more thing: production should never be where you debug. If something breaks in production, your job is to roll back fast — not to experiment fixes live. Vercel makes rollback trivial: Deployments tab → pick a previous deployment → Promote to Production. Ten seconds, done.

---

The Workflow That Protects You

Here's the three-environment workflow in practice:

# 1. Create a feature branch
git checkout -b feature/payment-flow

# 2. Build locally on dev — .env.local uses test keys
npm run dev

# 3. Push branch → Vercel Preview Deployment fires automatically
git push origin feature/payment-flow
# PR opens → Vercel posts preview URL in PR comments

# 4. Test on staging:
#    - Does the payment form work end-to-end?
#    - Do env vars load correctly?
#    - Any build errors in the preview logs?
#    - Stakeholder/QA approval on the preview URL?

# 5. Merge to main → Production deployment fires
git checkout main
git merge feature/payment-flow
git push origin main

The cost of skipping steps 3 and 4 is what happened to Marcus. And to plenty of teams with far more resources. According to Cockroach Labs' State of Resilience 2025 report — which surveyed 1,000 senior technology executives — 100% of respondents experienced outage-related revenue loss in the past year, with per-incident losses ranging from $10,000 to over $1 million. The organizations that handled incidents best had "already run the playbook dozens of times in controlled environments."

Staging is that controlled environment.

---

What AI Coding Tools Change About This

AI coding assistants can scaffold this three-environment setup in minutes. When starting a new Next.js project, you can prompt your AI tool:

"Set up a three-environment Vercel config with separate env vars for dev, staging (preview), and production. Include .env.local.example, .gitignore entries, and a vercel.json with environment-specific settings."

A well-configured vercel.json to anchor your production branch:

{
  "git": {
    "deploymentEnabled": {
      "main": true
    }
  },
  "build": {
    "env": {
      "NODE_ENV": "production"
    }
  }
}

AI tools are also useful for generating realistic seed data for your dev database, writing environment validation scripts that blow up loudly at startup if required env vars are missing, and automating the PR checklist that enforces staging review before merge.

The setup that took senior engineers an afternoon to configure a few years ago is now a 15-minute task with AI assistance. The discipline of using that setup — of never skipping staging — that part is still on you.

---

What Happens When You Skip Staging

Let's be concrete about the failure modes:

• Wrong API keys in production. Like Marcus. Your payments silently fail, integrations break, and you find out from an angry customer, not your logs.
• Database schema mismatches. You added a column in dev, forgot to run the migration before deploying. Production goes down.
• Feature flags that work in isolation but break in combination. You only discover this when real users hit the edge case you didn't test.
• Third-party webhook differences. Stripe test webhooks behave slightly differently from live ones. You won't know until production.
• Environment-specific build failures. Something works on your M2 MacBook that breaks in the Linux container Vercel uses for builds. Staging catches this. Your laptop doesn't.

As NTT DATA observed, skipping staging means you "can't compare the old and new configurations in a controlled environment, which can significantly delay resolution" when something breaks. That delay is measured in user-facing downtime and lost revenue.

---

Action Items

Before your next deploy, run through this checklist:

• ☐ .env.local is in .gitignore — never committed, never pushed
• ☐ Local dev uses test/sandbox API keys only — no live keys on your machine
• ☐ Vercel project has three env scopes configured — Development, Preview, Production — with different values where needed
• ☐ Stripe test keys are in Preview scope; live keys are in Production scope only
• ☐ Your production branch is main — Preview Deployments enabled for all other branches
• ☐ Every feature goes through a PR — so you get a Preview URL before merging
• ☐ Your staging database is separate from production — different connection string, no real user data
• ☐ You've tested a Vercel rollback at least once — so you can execute it fast when needed
• ☐ A .env.local.example file exists in your repo — so teammates know which vars they need without needing your secrets
• ☐ Environment variable validation runs at startup — your app fails loudly if a required var is missing

---

Ask The Guild

Have you ever pushed directly to production and watched something break in front of real users? What did it cost you — in time, money, or dignity?

Share your war story in the Guild community. Bonus points if you describe the exact moment you realized something was wrong. The community learns most from the disasters we've all lived through — and the systems we built afterward to make sure it never happens again.

---

Tom Hundley is a software architect with 25 years of experience. He writes the Production Ready series for the AI Coding Guild.