Production is the live version of your software that customers use. Staging is a separate copy, at a different address, where changes are checked first. Software needs both so that mistakes are found where they cost nothing. A change is reviewed on staging, approved, and only then released to production.
When we rebuilt a realtor's website and moved it off WordPress, the new site existed for a while at a temporary address. The old site kept running on the real domain. We built the new one, checked it page by page at that temporary address, and only then pointed the domain at it.
Nothing about that is clever. It is the ordinary way to replace something people depend on: build the replacement next to the original, confirm it works, then switch. The temporary address was a staging environment, and the real domain was production.
The idea applies to every project, from a small site to an application handling payments.
What is the difference between staging and production?
Production is the environment real customers use, with real data and real consequences. Staging is a private copy that behaves the same way and is used for checking changes before release. The difference is who is affected by a mistake: on staging, nobody outside the project.
| Staging | Production | |
|---|---|---|
| Who uses it | The developer and the client | Customers and the public |
| Address | A temporary or private one | Your real domain |
| Data | Test data, or a safe copy | Real customer data |
| Payments | Test mode, no real money | Live |
| Emails and texts | Held back or sent to test inboxes | Sent to real people |
| Visible to search engines | No | Yes |
| Cost of a mistake | A fix | Lost sales, lost trust, cleanup |
Developers also have a third environment, usually called local or development: the copy on their own computer where code is written. Staging sits between that and production.
Why does software need a staging environment?
Software needs a staging environment because some problems only appear when it runs on real hosting, at a real address, with all its parts connected. Code that works on a developer's computer can fail once deployed. Staging is where that failure happens privately.
It also gives the client somewhere to look. A description of a change is easy to misread. A working link is not. Reviewing on staging means you approve the thing itself, on your own phone, before any customer sees it.
For Homes by Jan, the goal was to retire WordPress without losing a single ranking, with every page and article at its exact original address. That is the kind of requirement that has to be verified, not assumed. Checking the rebuilt site at a temporary address meant the list of addresses could be tested against the new build while the old site was still serving visitors. The method is in migrating off WordPress without losing URLs.
What is a preview deployment?
A preview deployment is a temporary, complete copy of a site or app, built automatically from a proposed change and given its own address. Each change gets its own preview. Reviewers open the link, check the change in isolation, and the preview is discarded once the change is merged or dropped.
Hosting platforms such as Vercel, which we use for many projects, create these automatically when a change is proposed. The effect is a staging environment per change, instead of one shared staging site where several unfinished changes pile up together.
A preview link pairs naturally with automated checks. On CoverageCobra, a change cannot merge until type checks, lint, tests, and a build all pass. The checks answer "did this break anything", and a preview answers "is this what we wanted". We describe the checks in how software is tested before launch.
How does a change move from staging to production?
A change moves to production in a fixed sequence: it is written locally, published to a staging or preview address, checked automatically, reviewed by a person, approved, and then released. Each step can stop the change. Nothing reaches production by skipping the steps before it.
- Write the change on the developer's own computer.
- Publish it to a preview or staging address.
- Run the automated checks.
- Review it. The developer first, then the client for anything visible.
- Approve and merge.
- Release to production.
- Check production. A quick look at the live site confirms the release behaved the same way there.
The last step matters because staging is never a perfect copy. Differences in data and configuration are where surprises come from.
What should be different between staging and production?
Staging should match production in code and configuration, and differ in anything that touches real people or real money. Payments run in test mode, outgoing emails and texts are held back or redirected, search engines are blocked, and secret keys are separate from the live ones.
Getting this wrong causes real problems:
- Real customer data on staging. A copy of production data in a less protected place is a privacy risk. Use test data or a scrubbed copy.
- Live payment keys on staging. A test order should never charge a card.
- Staging visible to search engines. A public duplicate of your site can end up indexed.
- Shared secrets. Each environment should have its own keys, as covered in environment variables and secrets.
Does a small website need staging?
A small website needs a way to see changes before they are public, which is the purpose of staging, though it does not need a permanent second server. For a static site, a preview link per change does the job at little or no extra cost.
For a single correction to a phone number, going straight to production with a quick check afterwards is reasonable. The care should scale with the risk. A new page layout, a changed form, or anything involving payments or sign-in deserves a look on a preview first.
The case where staging is not optional is a replacement. If a new site is taking over a domain from an old one, build and check it elsewhere first. Switching the domain should be the last step. See what happens after a website launches for the checks that follow.
Frequently asked questions
Can customers see the staging site?
They should not be able to. Staging is normally at an unpublished address, often behind a password, and blocked from search engines. Ask your developer how yours is protected.
Does a staging environment cost extra?
It depends on the hosting. For static sites and many modern platforms, preview deployments are part of the service. For applications with a database, a second environment means a second database, which carries some cost.
What is a rollback?
A rollback is returning production to the previous working version after a bad release. Good hosting makes this a single action. Ask whether it is possible before you need it.
What does "it works on my machine" mean?
It is the developer's version of a shrug: the code ran on their own computer and failed elsewhere. Staging exists to catch that gap before customers do.
Should I be given access to staging?
Yes. Reviewing work before release is the client's part of the process.
If you are replacing a site or launching an app and want it checked somewhere safe first, talk to us.