Pushing to a Live Shopify Theme Without Breaking the Store

Two ways to deploy, and why one is safer

There are two routes to getting new code onto a live Shopify storefront, and they carry very different risk.

Push over the live theme

shopify theme push --allow-live --store client.myshopify.com

The CLI requires --allow-live specifically because this is the dangerous one. Files upload individually over a theme that is serving customers, so for the duration of the upload the storefront is running a mixture of old and new code. New CSS with old markup renders as a broken page — to real visitors, mid-session.

Publish a prepared theme

# Upload to an unpublished theme
shopify theme push --unpublished --theme "Release 2026-09-23" --store client.myshopify.com

# QA it, then make it live in one atomic step
shopify theme publish --theme 987654321 --store client.myshopify.com

Same result, materially different risk profile. The upload happens somewhere nobody is looking, you QA the finished article, and the switch is atomic. Rollback is republishing the old theme.

The two steps everyone skips

1. Duplicate the live theme

Before anything else, take a copy of what's currently live. This is your rollback and it takes seconds. Without it, "put it back how it was" has no answer — and that request always arrives at the worst time.

# Pull the live theme to disk and commit it
shopify theme pull --theme 987654321 --store client.myshopify.com --path ./rollback
git add ./rollback && git commit -m "rollback point before 2026-09-23 release"

A duplicate on the store is faster to restore. A git commit survives someone deleting themes to free slots. Do both if the store matters.

2. Pull before you push

Between your last sync and right now, the merchant may have changed section settings, an app may have injected code, or someone may have hotfixed something in the admin. All of that lives in files your push is about to overwrite.

shopify theme pull --theme 987654321 --store client.myshopify.com
git status          # anything here is a change made on the store
git diff --stat     # decide deliberately what to keep

If that pull comes back with changes to settings_data.json or template JSON, stop and look. That's a merchant's work, and deploying over it is the incident described in every other article about this.

Pre-deploy checks worth the two minutes

Cheap, fast, catch a disproportionate share of real problems.

shopify theme check --path .

Theme Check finds Liquid syntax errors, undefined objects, deprecated filters and common performance mistakes. A Liquid error on a live product template can take a page down entirely, and this catches it in seconds.

When to deploy, and when not to

Timing is a real control, and it's free.

• Know the store's quiet hours. Not yours — theirs. Check the merchant's analytics for the actual trough. It's often not the middle of the night.
• Never deploy into a promotion. An email send, a paid campaign or an influencer post means peak traffic on the exact pages you're changing.
• Freeze around peak season. Late November through December, most stores should accept only critical fixes. Say this in advance and put it in the schedule.
• Not last thing on a Friday. Standard advice, and it holds: deploy when someone is around to notice and fix.
• Tell the merchant when. Not for permission — so that if they see something odd they know it's you, and check with you rather than panicking.

Rolling back when it goes wrong

Decide the rollback trigger before you deploy, because judgement degrades once a storefront is misbehaving. A useful default: if it isn't fixed in ten minutes, revert and diagnose on a staging theme.

# If you published: republish the previous theme
shopify theme publish --theme 111111111 --store client.myshopify.com

# If you pushed over live: push the rollback copy back
shopify theme push --allow-live --path ./rollback --store client.myshopify.com

Then write down what happened and which step would have caught it. Nearly every live-theme incident traces back to a skipped duplicate or a skipped pull.

How ThemeSync handles deploys

• Deploys pull before they push. The deploy flow captures store-side changes first, so a merchant edit made minutes earlier isn't silently overwritten by your release.
• Draft and live pushes are separate, explicit actions. Pushing to an unpublished theme and pushing to the published theme are different buttons, so --allow-live is never something you do by accident.
• Theme Check runs from the same place. Linting is part of the flow rather than something you remember on a good day.
• Duplicating a theme is one action. Taking a rollback point before a release doesn't require assembling commands.
• Live themes are tracked in git. Every sync commits what changed on the store, so a rollback point exists even when nobody explicitly made one.
• QA and sign-off attach to the theme. Screenshots and client approvals are recorded per page and viewport, so "what did we verify before publishing" has an answer afterwards.

Takeaways

• Publish a prepared theme rather than pushing over the live one. It's atomic, QA-able and trivially reversible.
• --allow-live exists because it's dangerous — customers see a mixed old/new state during the upload.
• Duplicate the live theme before you start. That's your rollback, and it takes seconds.
• Pull before you push. Anything the pull brings back is a change you'd otherwise have destroyed.
• Run theme check, then test add-to-cart on mobile on the exact theme you're publishing.
• Deploy in the store's quiet hours, never into a promotion, and freeze around peak season.
• Agree the rollback trigger in advance. Ten minutes, then revert and diagnose on staging.