Shopify development stores and staging: how to work without breaking live

Shopify does not give you a staging environment in the way a self-hosted platform does. There's no clone of production sitting at staging.example.com with the same orders and customers. What it gives you instead is three separate tools, and using them properly is the difference between a controlled release and a customer watching your product page break.

The three tools

Development stores. Free stores created from a Partner account, used to build from scratch or to prototype. They can't take real orders, and they don't have your live data unless you put it there. Right for building a new store, wrong for testing a change against a real catalogue.

Unpublished themes. A copy of your live theme, sitting in the same store with the same products, orders and apps, not serving customers. This is the closest thing to staging Shopify has, and it's what you should use for almost all work on an existing store.

Preview links. A shareable URL that renders an unpublished theme against live data, so a client can review without anyone publishing anything.

The workflow for an existing store

1. Duplicate the live theme. Name it something with a date and a purpose — live-copy-2026-09-08-search-filters beats Copy of Copy of Dawn.
2. Work on the duplicate, ideally through the Shopify CLI so changes are in version control rather than only in the admin.
3. Preview and review using the preview link.
4. Test on a phone, not only in a desktop browser at a narrow width.
5. Publish, keeping the previous version unpublished as an instant rollback.
6. Don't delete the old theme for a week. Rollback should be one click, not a restore from a download.

What the theme copy does not include

This is the trap. A duplicated theme shares the store's data and apps with the live site. So:

• Editing products, collections or metafields while "testing" changes them for real customers. There is no isolation.
• App settings are shared. Changing an app's configuration to test something changes it live.
• Anything an app injects into the theme may not be present in your copy, or may behave differently.

If what you're changing touches data or app configuration rather than just theme code, a development store with a representative export is the safer environment — accepting that you then have to replicate the change on live afterwards.

Version control

The admin's code editor has no history worth the name. Use the Shopify CLI to pull the theme into a repository and push changes from there. That gives you a diff for every change, a way back, and a way for two people to work without overwriting each other.

It also means the code is genuinely yours. If a developer builds a theme that only exists in your admin, you have a store, not an asset — handover should always include a repository.

What "working on live" is actually acceptable for

Being honest about it: changing a headline, swapping a homepage image, publishing a blog post. Content edits.

Anything that touches code, sections, templates or settings should go through a duplicate. A developer who proposes to edit the live theme for substantial work is telling you they'll break something in front of customers eventually — which is why it heads the list of red flags.

Before you publish

Run the relevant part of the launch checklist even for a small release: the templates you touched, on a phone, plus one real transaction if you went anywhere near cart or checkout.

The rollback plan is the part of a release nobody plans, and the only part you need under pressure. On Shopify it's free: leave the old theme sitting there, unpublished, for a week.