Executive summary
- What: Hydrogen storefronts can now be deployed to Oxygen from development stores. Oxygen hosting previously required a paid plan.
- Why: headless prototypes and pre-launch builds can run on the production runtime before any billing relationship exists.
- Who: brands evaluating headless, agencies building Hydrogen storefronts, and platform teams standing up early environments.
What changed
Oxygen is Shopify's hosting runtime for Hydrogen, a worker-based JavaScript environment built on Cloudflare's workerd. Access to it used to begin at the paid plans. It is now available on development stores as well, which means a Hydrogen project can be deployed and exercised on the real runtime while the store is still a testing environment.
One constraint carries over. Development stores do not include public environments, so every deployment URL requires a store login. You can share a build with anyone who has access to the store, but you cannot hand the URL to an outside stakeholder or point an unauthenticated load test at it. Oxygen also remains unavailable on Agentic plans.
Why it matters
Headless evaluations have historically run somewhere other than Oxygen: a generic Node host, a container, whatever the team already knew. That is a reasonable way to prove out React and the Storefront API, but it tells you very little about how the storefront will behave on the runtime you actually intend to ship on. Oxygen is a worker runtime and a number of Node APIs are simply absent from it. Discovering that after the commercial decision has been made is an expensive way to learn it.
Deploying to Oxygen from a development store moves that discovery to the beginning of the project. Caching behaviour, cold start characteristics, environment variable handling, and the deploy pipeline itself all get exercised while the architecture is still cheap to change. For agencies it also removes a real piece of friction from the evaluation stage, since a working prototype no longer requires the client to put a store on a paid plan first. We covered the broader picture in the role of Hydrogen and Oxygen in enterprise headless commerce.
Role-specific impact
- Marketers: campaign templates and content structures can be reviewed on the real storefront much earlier. Budget for the fact that the preview URL is login-gated, so external reviewers need store access before they can see anything.
- Developers: the deploy path is the same from day one. CI can push to Oxygen from a development store, so nothing about the pipeline changes at launch except which store it targets.
- Store admins: a new class of environment to track. Development store deployments still consume Oxygen environments and should be named clearly and retired deliberately once an evaluation ends.
Use-case example
Real-world scenario
A specialty retailer runs a six-week headless evaluation before committing to a rebuild. Under the old constraint that prototype would have lived on a generic Node host, and the team would have discovered during the port to Oxygen that two of its dependencies relied on Node APIs the worker runtime does not expose.
Starting on Oxygen instead surfaces those in the first week, when swapping a library costs an afternoon rather than a sprint. On a six-week evaluation that is close to two weeks of schedule recovered, and the performance numbers the team presents at the end are measured on the runtime that will serve production traffic rather than on a stand-in.
Implementation checklist
- Confirm you have a development store and the organization permissions to create deployments against it.
- Install the Hydrogen channel on the store to enable Oxygen access.
- Link your local Hydrogen project to the store and deploy through the Shopify CLI.
- Expect the deployment URL to require a store login. Plan reviewer access around that rather than treating the URL as shareable.
- Check the Oxygen runtime documentation for unsupported Node APIs before you commit to dependencies.
- Point CI at the same deploy path now, so no new mechanism is introduced at launch.
- Name environments so it is obvious which belong to the development store, and retire them when the evaluation closes.
FAQ
Q: Can we share a development store Oxygen URL with a client or an external reviewer?
A: Only if they have access to the store. Development stores have no public environments, so the deployment URL always sits behind a store login. Public environments come with a paid plan.
Q: Is a development store deployment a fair performance test?
A: For runtime behaviour and code-level performance, yes, it is the same worker runtime. For anything that depends on public traffic, edge caching under real load, or third-party scripts firing for anonymous visitors, wait until you have a public environment.
Resources
Hydrogen and Oxygen supported plans
Need guidance? Talk to Makro.