How we stage a live store before we touch it

Every store we run has a staging copy, and every upgrade, patch and new extension goes there first. It sounds obvious. It is also the step most stores skip, which is why “we updated a plugin and checkout stopped working” is still the most common first message we get from a new client. Here is how we build a staging environment that is actually safe to use, for Magento and for WordPress.

What staging is for

A staging site has one job: let you break things without customers noticing. That means it must be a faithful copy of production, close enough that a problem on staging predicts a problem on live, and it must be sealed off so that nothing it does leaks out. Most “staging” sites fail one of those two tests. Either they are a months-old snapshot that no longer resembles the real store, or they are a live copy that quietly emails real customers and pings real payment gateways.

A faithful copy

We clone from production, not from a backup of unknown age. Files, database, media and configuration, refreshed on demand before a round of testing so the catalogue, customers and orders are current. For a recent Magento B2B store the clone was rebuilt from live the morning we started an upgrade cycle, so the dealer accounts and price lists we tested against were the ones that would be on the line.

The copy runs on the same major versions as production, or on the versions we are about to move production to. Testing a PHP upgrade on staging only tells you something if staging actually runs the new PHP.

Its own database, its own everything

Staging never shares a database with production, and on a shared host it gets its own database server as well. On one store we run staging in a separate database container so that a migration script run on the wrong terminal cannot touch live data at all. The staging application user has no credentials for the production database, full stop.

The same applies to caches, search indexes, cron jobs and file storage. A staging site that shares a Redis instance or an Elasticsearch index with production will corrupt one with the other the first time an upgrade changes a schema.

Sealed off from the world

This is the part people get wrong. A clone of a store contains every customer’s email address and, often, a connection to a live payment gateway, courier account and email service. Before anyone logs in to our staging copies we do four things:

• Outbound email is disabled at the application and the server. Not “set to test mode”, disabled. Order confirmations, password resets and newsletter sends from staging go nowhere.
• Payment and shipping integrations are switched to sandbox keys or removed. A test order on staging must never reach the real gateway.
• Search engines are kept out. HTTP basic authentication in front of the whole site, noindex headers behind that, and robots.txt as a last resort. A staging site that gets indexed competes with the real store for its own keywords.
• Integrations are pointed at test endpoints or disabled. An ERP sync that runs on staging against the live ERP will create real orders. We have seen it.

What we test before anything goes live

Once the clone is sealed, the checklist is the same every time: log in as a customer, add to cart, apply a discount, check out with the sandbox gateway, confirm the order lands in the admin, change a password, submit a contact form, run the ERP sync against the test endpoint, and click through the ten most-visited pages. For Magento we also rebuild static content from scratch and check the integrity hashes match what the server serves, because that is the step that has broken checkout for more stores than any extension.

Only then does the same change go to production, in a maintenance window, with the staging run as the script.

Keeping it alive

A staging site rots. Data drifts, versions drift, people forget it exists. We refresh ours from production on a schedule and before every upgrade cycle, and we treat a broken staging site as a priority, because the alternative is testing on live.

If your store does not have a staging copy, or has one nobody trusts, that is a hosting conversation before it is a development one.