The staging strategy for a store that never stops trading

Shopify does not give you dev, staging and production. It gives you four places to work, each with different fidelity, and most staging arguments are really an argument about which one a particular change belongs in.

Local, with `shopify theme dev`. Fastest loop, runs against your store’s real data through the CLI. This is where code gets written. It is not where anything gets signed off, because it is one developer’s machine and nobody else can see it.

An unpublished theme on the live store. The highest-fidelity front-end environment that exists. Real products, real inventory, real prices, real apps, real traffic conditions — and a preview URL you can send to a client. Shopify allows up to 20 themes in the library with one published, so a theme per active branch is comfortably within reach for most teams. This is where review and sign-off happen.

A development store. A separate store you can break. Lower fidelity — different data, apps that may need reinstalling, sometimes a different plan — but it is the only place you can safely test anything that writes. Orders, refunds, inventory movements, webhook deliveries, an ERP integration: all of it here.

Production. Not an environment. A publish button.

The rule that follows is short enough to put in a README: if the change only affects what a page renders, stage it on an unpublished theme. If it changes what happens after someone clicks buy, stage it on a development store.

This is the constraint people hit first and argue with longest. To place test orders you either put Shopify Payments into test mode or enable the test payment gateway, and Shopify is explicit about the consequence: customers can’t place live orders while your payment providers are in test mode. On a store that trades continuously, that is an outage you have chosen.

The alternative Shopify offers — place a real order through a real provider, then immediately cancel and refund it — works and has costs. You may still pay processor fees, and more importantly the order is real everywhere downstream. It hits your ERP, your 3PL integration, your accounting export and your analytics, each of which now contains a transaction that was not one. For a single smoke test after a payment configuration change that is an acceptable trade. As a way of testing a new checkout flow, it is not.

So the awkward fact stands: checkout is tested on a development store or it is tested in production on real customers. Build the development store properly, because the alternative is worse than it looks.

For a front-end release, the sequence is short and the value is all in the last item.

Review on the unpublished theme against the live one at three widths. Confirm which settings are being carried across and which are being left alone. Publish. Walk the critical paths on the real store immediately — home, a collection, a product with variants, add to cart, into checkout as far as the payment step. Then watch conversion and JavaScript errors for an hour rather than declaring victory in a channel.

The rollback plan is the part teams skip because it feels superstitious. It should not: the previously published theme is still in the library unless somebody deleted it, and republishing it puts the store back in seconds. That is a better rollback than most applications have. It costs one of your 20 theme slots, which is the cheapest insurance on this list. Keep at least the last known-good version, and prune old branches rather than old releases when the library fills up.

The one thing a theme rollback does not undo is a settings change. If the release included new sections with new settings, republishing the old theme restores the old arrangement — which is usually what you want, and worth knowing before you need it.

Everything above concerns the theme. Custom apps and integrations need their own answer, and it is a more conventional one.

A custom app has staging in the ordinary sense: its own hosted instance, its own database, its own credentials, pointed at a development store. What makes it awkward is that the other side of the integration frequently has no sandbox. Your ERP might; your 3PL might not; a legacy system almost certainly does not. Where there is no sandbox, the realistic approach is a recording of real payloads replayed against your staging instance, plus a hard rule that staging credentials cannot reach a production endpoint. That rule needs to be enforced in configuration, not in a person’s memory.

Webhooks deserve particular care because they are the most common source of the worst kind of accident: a staging app subscribed to a production store, quietly processing real orders. Subscriptions are per store, so keep the development store’s webhook targets and the production store’s in separate configuration that cannot be copied between them by accident.

And check the apps themselves. An app installed on your development store may be on a different plan, a different version, or absent entirely — which means a front-end change that depends on an app is one of the few cases where the development store is the *less* faithful environment, and the unpublished theme is the right place to test it.

Resist the pyramid. Teams coming from application development often try to build four tiers with data syncing between them, and on Shopify the maintenance of that exceeds the risk it removes. The cheapest setup that works:

One repository with a branch per change, connected to unpublished themes for anything that needs review. One development store, kept installed and configured, for anything that writes data. A written rule about which changes go where. A deploy that never pushes settings without someone deciding. And the previous theme left in the library after every publish.

That is a weekend of setup and it covers most of what a trading store needs. If you want the next step up, it is not another environment — it is automating the checks on the one you have, which we covered in [theme CI](/blog/theme-ci-testing-a-shopify-theme-before-it-ships).

The thing most worth protecting is the habit rather than the tooling. Stores that stay stable are not the ones with the most environments; they are the ones where nobody has pushed to the live theme from a laptop in two years. That discipline is most of what a [maintenance and store management arrangement](/services/support) is actually buying.

• Shopify maintenance and support
• Theme CI: testing before you ship
• The migration dry run