Multiple environments with headless Shopify

What is a multi-environment Shopify setup?

A multi-environment setup allows for isolated development and testing to take place away from your production/live store. This involves configuring and maintaining multiple distinct, separate environments that share similarities such as overall configuration, content architecture, and a common frontend, while remaining fundamentally disconnected. With Headless Shopify, this ensures that ongoing development and feature enhancements can be tested and prototyped in isolation from the production store, and only made available to end-users once validated and approved.

Pushing large updates directly to a production store is risky, as mishaps can negatively affect user experience – and potentially cause errors that result in downtime or broken pages. With a multi-environment setup, you can safely develop and prototype changes in isolation from the production storefront prior to deploying them to production.

Why are multiple environments important?

The ability to maintain multiple environments (i.e. development, staging, and production) is critical for any e-commerce store that attracts a high volume of users, or turns over a high volume in sales. Fast-moving brands require agility; something that can only be achieved with the ability to prototype changes, deploy new features, and iterate on the store experience with a safe, multi-step environment workflow.

For micro-stores or micro-businesses, one may potentially be able to get away with a single environment, a slightly scrappy development practice, some luck, and frequent use of the “undo” button.

But for stores turning over millions of dollars in annual revenue, or sites with a healthy, continual flow of traffic, the lack of sufficient environment control is embarrassing at best, and catastrophic at worst. This is compounded an infinite number of times when the principal e-commerce platform (or engine) is closed-source and without a backup and rollback facility.

Whether the proposed changes are at the content level, pricing & inventory level, theme/presentation level, or involve changes in either storefront or operational behaviour, a lack of robust environment management has potential to cause chaos and lost sales in the event of human error or software malfunctions.  

We're the experts in Headless Shopify.

Your search for answers ends here. Discover our services.

Explore Headless Shopify Services

Benefits of a multi-environment setup

• Ability to test changes and preview them prior to production deployment, in multiple environments
• Testing out of new apps and their compatibility with the headless storefront, including any customizations or workarounds required to fully integrate the App with the headless storefront
• Testing of design changes or modifications that affect the headless store’s presentation layer 
• The ability to build out large scale feature/functionality changes over a period of weeks or months without it having an impact on the production store
• To safely update Shopify API versions over time, and test them thoroughly without implicating the production environment

Does native Shopify provide an easy way to manage multiple store environments that support a multi-step deployment workflow?

Unfortunately, this isn't something that Shopify themselves readily provide for non-headless stores – as of 2025. While it's possible to manually duplicate parts of a store via CSV export and import, this isn't agile, and it's a pain.

Some apps exist to help the process, but currently, there isn't a straightforward, fail-safe way to work with multiple environments on Shopify natively. 

Multiple frontend environments or deploys with Headless Shopify

Headless Shopify storefronts use Git-based repositories for tracking and source control. With a Git repo, it’s common practice to use multiple branches, with each typically centred on a specific functionality, feature addition, or interface change. Branches allow different versions of the headless frontend’s codebase to exist simultaneously, so that changes can be developed without directly impacting the primary production branch (usually referred to as the main, or master, branch)

As we discuss in our CI/CD resource, a headless Shopify storefront will be deployed via a CI pipeline. Individual pipelines can be configured for each branch, allowing for multiple versions of the storefront to be deployed. This caters to a variety of use cases, but for the purpose of this resource, let’s focus on the benefits of this from a multi-environment point of view.

Deploying multiple instances of the headless shopify frontend is as simple as initiating a new CI pipeline separate of the production pipeline, and deploying to a separate domain or subdomain. This alone, however, doesn’t provide any added value for staging and feature development. In order to achieve two or more environments with distinct differences in the frontend and/or backend, more setup will be required in the form of branch based deployments, and deployment-based environment variables.

Branch based deployments

Headless Shopify storefronts can make use of branch-based deployments, which will allow changes to the frontend (and any middleware) to be staged and tested in isolation of the production storefront on a separate domain.

Branch-based deployments rely on your development team isolating new features and storefront updates within individual Git branches so that they can be deployed and staged separately.

Each branch can be used to develop, stage, and test individual feature additions or interface changes to the storefront, prior to merging them with the production branch.

Informal chat? Works for us. 🤘

Contact Cocoon for a no-cost, no-obligation consultation.

Let's talk Shopify

Pointing different frontend branches to Shopify development stores

If each branch is built via a separate pipeline, they can each be hosted on their own domain or subdomain, and specify different values for their respective environment variables.

Here’s where the magic lies in terms of staging backend changes, and how these changes affect the staged frontend.

What are environment variables?

Environment variables (or env vars) are deployment-specific “keys” that are used to define things like access tokens, endpoint domains, or API versions. They’re usually used for sensitive, deployment-specific variables that are liable to change between each environment you intend to set up.

With shopify headless, your env vars will usually consist of a few keys, but most notably the Shopify access tokens and secrets required in order to call the Shopify APIs, as well as the Store URL to define the Store for which you’re querying.

This allows for the same headless storefront to query different Shopify stores, retrieving data relevant to the target backend.

For multi environment setups, this means that changes on the storefront can be safely tested with a staging Shopify store, or backend/configuration changes in Shopify can be tested with the headless storefront prior to production.