All posts
4 min read

Dev, Staging, and Production Explained

Professional apps don't have one copy — they have several, so changes can be tried safely before real users see them. What development, staging, and production environments are, why they need separate databases and keys, and the simplest version that works for a small app.

deploymentgetting startedno-codebeginner

When you're just starting, there's one copy of your app: the one you're building. Then you launch, and suddenly there's a problem. Every change you make, you're making to the thing real people are using. Try something risky and it breaks for everyone.

The solution professionals use is to run several copies of the app, called environments, each with a different job.

The three classic environments

Development ("dev")

Where you build. Usually your own computer, or a cloud workspace. It's expected to be broken half the time — that's the point. You (or your AI agent) try things here.

  • Uses fake or test data
  • Uses test keys for services (Stripe test mode, and so on)
  • Only you see it

Staging

A dress rehearsal. A copy set up as close to the real thing as possible — same kind of hosting, same settings — where you check a change works properly before it goes live.

  • Uses realistic test data (never copied real customer data)
  • Still uses test keys
  • You, your team, or a client check it

Production ("prod")

The real app, used by real people, with real data and real money.

  • Real data — handle with care
  • Live keys
  • Changes arrive only after they've been checked

Why separate environments matter

Mistakes stay contained. An AI agent that deletes a table in development costs you a few minutes. The same command in production could cost you your customers' data. (How to Stop an AI Agent From Deleting Your Production Database)

You can check before it's live. "It works on my computer" isn't the same as "it works on the real hosting." Staging catches the difference. (Why Does My App Work Locally but Not in Production?)

Test payments aren't real payments. In development and staging, you can buy your own product a hundred times using test cards.

Real data stays private. Customer data lives only in production, not on laptops and test servers.

What must be separate

For environments to protect you, each needs its own:

  • Database. This is the big one. Development must never point at the production database — not even "just to test one thing."
  • API keys and secrets. Test keys in dev and staging; live keys only in production. Environment variables make this easy — same code, different settings. (What Is an Environment Variable?)
  • URL. So you always know which one you're looking at — for example yourapp.com for production and staging.yourapp.com for staging.
  • Email sending. Staging shouldn't email real customers. Use a test mode, or send only to your own addresses.

Preview environments: staging for every change

A modern variation: instead of one shared staging environment, many hosts create a temporary copy of the app for every branch or pull request, with its own URL. You open the link, check that one change, and merge it when it's right. (Preview Environments for Every Branch.)

For a small app, preview environments often replace staging entirely.

How changes move through

A typical flow:

  1. Build the change in development, on a git branch.
  2. Open a pull request. A preview or staging version is created.
  3. Check it there — click through, run the tests. (How to Test Your App Before Launch)
  4. Merge. The change deploys to production.
  5. Watch production for errors.

Nothing reaches real users without passing through a place where it was checked. (What Is a Pull Request?)

The simplest version for a small app

You don't need a big setup. A perfectly good starting point:

  • Development: your computer or a cloud workspace, with its own database and test keys.
  • Production: your live app, with its own database and live keys.
  • Previews or a staging URL if your host offers them.

The one rule that matters most: development and production never share a database. If you get only that right, you've avoided the most damaging mistake.

Common mistakes

  • Testing on production "just this once." It's always "just this once."
  • Copying production data to development to "test with real data." Use generated test data instead.
  • Mixing up keys — a live Stripe key in development, or a test key in production (payments that never really happen).
  • Forgetting a setting in production — something configured in dev but never added to the live environment.
  • Not knowing which environment you're in. Give staging a visible banner or a different colour so nobody confuses it with the real thing.

The summary

  • Development: build and break things. Staging/preview: check. Production: real users.
  • Each needs its own database, keys, and URL.
  • Changes flow dev → preview/staging → production, checked on the way.
  • Minimum viable setup: separate dev and production databases.

EasySpawn gives each project a development workspace with its own managed database, and a live URL per branch on Pro — so changes are checked in a real environment before they reach production. See how it works or join the waitlist.

Related: What Is Localhost? · Zero-Downtime Deploys for a Small App · What Is CI/CD? · Backups for Beginners

Keep reading