Shopify theme backup: the complete guide

29 July 2026 · 7 min read

A Shopify theme backup is a complete, dated copy of every file your theme is built from — kept somewhere you can get it back after the original has changed. That definition sounds obvious until you check what most stores actually have, which is a theme duplicated once, months ago, named "Copy of Dawn".

This guide covers what a backup has to contain to be worth anything, what Shopify keeps on your behalf, where the gaps are, and a routine that survives contact with a real store.

What a theme backup has to contain

A theme is not just its templates. If a backup skips any of these, the restore will be incomplete in a way you only discover under pressure:

• layout/ — theme.liquid and any alternate layouts
• templates/ — including JSON templates, which hold section order and settings
• sections/ and blocks/ — the structure merchants edit in the theme editor
• snippets/ — the small partials everything else depends on
• assets/ — CSS, JS, images and fonts the theme ships with
• config/ — settings_schema.json and settings_data.json, where your theme settings live
• locales/ — translated strings, easy to forget and painful to redo

config/settings_data.json is the file people most often lose. It holds your colours, fonts, section defaults and every setting configured through the theme editor. A backup without it restores the theme's code but not the store you designed.

What Shopify keeps for you — and what it doesn't

Shopify is not careless with your data, but it is not a version control system either. Two facts matter:

Publishing a theme does not delete the old one. The previously published theme moves back into your theme library, unpublished. So the single riskiest action — going live with a new theme — is already reversible, as long as nobody deletes the old theme afterwards.

Editing files, on the other hand, is not versioned. When you change a file in the code editor and save, the previous content of that file is gone from the admin. There is no per-file history to scroll back through, no diff, no "restore this version". The same applies to changes made through the theme editor, which saves as you work.

That asymmetry is the whole problem. The big, scary, deliberate action is recoverable. The small, routine, everyday action is not.

Why "just duplicate the theme" stops working

Duplicating a theme is a real backup — for that moment. It breaks down as a routine for three reasons:

1. Your theme library is capped (20 themes on most plans at the time of writing), so a duplicate-per-change habit hits a wall within weeks.
2. Duplicates are unlabelled by default. "Copy of Copy of Dawn" tells you nothing about when it was taken or why.
3. Nobody duplicates before a small edit. The habit only survives for big changes, which are the ones already protected by the publish behaviour above.

A backup routine that actually holds

The routine below is deliberately boring. Backups fail because they depend on someone remembering, so the goal is to remove remembering from the process.

1. Capture on publish, automatically

The moment a theme goes live is the moment its exact state matters most, because that is what customers are seeing. Capture the whole theme then, without anyone deciding to.

2. Capture before anything writes to a theme

Any tool — including this one — that writes files into a theme should copy the destination first. Not only the files it is about to touch: the whole theme, so the theme can be returned to its previous state rather than half of it.

3. Keep enough history to cover the delay

Damage is usually noticed days after it happens: a customer mentions a broken page, or someone finally checks the mobile layout. History shorter than that delay is history that expires before you need it.

4. Be able to compare, not just restore

"Something changed and the page broke" is only actionable if you can see what changed. A file-by-file comparison between two themes turns a vague fault into a specific line.

Restoring without gambling the live theme

Restoring straight over the live theme means the fix and the risk land at the same moment: if the backup was not what you assumed, customers see the result immediately.

Rebuilding the backup as a new, unpublished theme avoids that entirely. You get the restored state as its own theme, preview it, compare it with what is live, and publish only once you have looked. The live theme is untouched until you decide.

Where Auto Theme Sync fits

Auto Theme Sync captures every file in a theme — templates, sections, snippets, assets, config and locales — and keeps a dated history you can search. A backup is taken automatically when a theme is published, and again before the app writes anything to a theme. You can compare any two themes file by file with a colour-coded diff.

Being straight about the current limitation: writing files back into a theme requires a permission Shopify grants separately, and that approval is still pending for this app. Backups, automatic capture on publish, comparison and history all work today. See the docs for exactly what is and is not available.

Related reading: Does Shopify back up your theme? and how to restore a theme file you overwrote.

Keep reading

Shopify staging theme: a workflow that does not lose work
How to run a Shopify staging theme properly — where to make changes, how to move them live, and how to avoid the drift that makes staging useless.

Shopify theme version control: what agencies actually use
Shopify keeps no file history of its own. The real options for Shopify theme version control: Git, the GitHub integration, CLI pulls, automatic capture.