Hydrogen vs Oxygen: Shopify's Headless Stack Explained
Hydrogen is Shopify's React framework for building headless storefronts. Oxygen is Shopify's hosting platform for running them. They aren't two options you choose between — they're two halves of the same stack. This trips up a lot of teams evaluating headless Shopify development, because the names sound like competing products. They're not. Hydrogen writes the code; Oxygen runs it.
Hydrogen is Shopify's React framework for building headless storefronts. Oxygen is Shopify's hosting platform for running them. They aren't two options you choose between — they're two halves of the same stack. This trips up a lot of teams evaluating headless Shopify development, because the names sound like competing products. They're not. Hydrogen writes the code; Oxygen runs it.
Getting the split straight matters because it changes what you're actually paying for, and where you have real architectural choice. This post covers what each layer does, where the boundary sits, when you'd deploy Hydrogen somewhere other than Oxygen, and the setup calls an India-based team needs to make. For the fuller headless picture, our headless Shopify guide covers architecture and cost end to end.
For Mumbai and broader Indian ecommerce teams, this has a direct budget impact. Oxygen's included hosting removes a recurring AWS or Vercel bill in USD that would otherwise scale with traffic — a real saving when the rest of the project is already quoted in INR against a tight DTC budget.
What Hydrogen Actually Is
Hydrogen is Shopify's opinionated React framework, built on Remix, for building custom storefronts against the Shopify Storefront API. It ships as a set of npm packages: scaffolding, pre-built components, GraphQL codegen, and caching primitives tuned for commerce data.
Think Next.js with Shopify's opinions baked in. You get server-side rendering by default and streaming responses. Components like <Money>, <CartProvider>, and <ProductProvider> map directly to Storefront API objects, so you're not hand-rolling cart logic from scratch.
Shopify maintains Hydrogen actively. The current major version tracks Remix releases closely and typically picks up new Storefront API fields within weeks of each quarterly API version release.
Hydrogen is not a hosting product. It's a codebase you clone, extend, and build. Nothing about the framework requires any particular server or edge network — that's a separate decision, and it's exactly where Oxygen enters the picture.
What Oxygen Actually Is
Oxygen is Shopify's managed edge hosting platform, built on Cloudflare Workers, purpose-built to run Hydrogen apps close to the shopper. Deploy to Oxygen and your storefront runs across Cloudflare's global edge network of over 300 points of presence, instead of a single origin server.
Oxygen handles the operational load a headless team would otherwise own directly: SSL, CDN, auto-scaling, deploy previews per pull request, and rollback. It's included at no extra cost on Shopify plans that support Hydrogen deployment (Basic and above).
That's a real difference from self-hosting, where compute and CDN become billable line items on top of your Shopify subscription. A team hosting the same storefront on AWS pays for both.
Oxygen is not a framework. It doesn't dictate your component structure, data-fetching patterns, or styling approach. It only cares that what you deploy is a Hydrogen, Remix-compatible build output. The framework and the host are independent decisions Shopify happens to package together well.
How They Fit Together
The relationship is linear: you write a storefront in Hydrogen, then deploy that build to Oxygen or an alternative host. Every shopper request hits Oxygen's edge network first. It runs your Hydrogen server code, calls the Storefront API for product and cart data, and streams HTML back to the browser.
| Layer | Hydrogen | Oxygen |
|---|---|---|
| What it is | React/Remix framework | Edge hosting platform |
| Built on | Remix + Storefront API | Cloudflare Workers |
| What it controls | Components, routing, data fetching, caching logic | Where code runs, SSL, scaling, deploy previews |
| Cost | Free, open source | Included with qualifying Shopify plans |
| Alternative | Next.js, Nuxt, SvelteKit against Storefront API | Vercel, Netlify, AWS, self-managed Node |
A useful mental model: Hydrogen is to Oxygen what a Next.js app is to Vercel. Vercel is built to run Next.js exceptionally well, but Next.js apps run fine elsewhere too. The pairing is optimised, not mandatory.
Can You Deploy Hydrogen Without Oxygen?
Yes. Because Hydrogen builds on Remix, it produces a standard Remix server build that runs on any Node.js-compatible host: Vercel, AWS via a Remix adapter, or a self-managed container. Shopify doesn't lock the build artifact to its own infrastructure.
Teams do this for a few concrete reasons. If your organisation already standardises on AWS or Vercel for compliance or billing consolidation, running Hydrogen there avoids introducing a second hosting vendor relationship.
If you need infrastructure features Oxygen doesn't expose, self-hosting gives you that control. Custom edge middleware beyond what Cloudflare Workers allows, or specific data-residency requirements, are the usual triggers. Regulated industries like financial services or healthcare-adjacent commerce fall into this category most often.
In our work on headless Shopify projects, we default to Oxygen for the large majority of builds. The reasons to move off it are narrow and usually organisational, not technical.
Why You Rarely Would Deploy Elsewhere
Oxygen removes real operational cost that self-hosting reintroduces. Deploy elsewhere and someone on your team now owns CDN configuration, cache invalidation, SSL renewal, and scaling policy. Oxygen handles all of that automatically and includes it with your Shopify plan.
There's also a request-path argument. Oxygen's Cloudflare Workers runtime sits on the same network Shopify's own APIs increasingly route through. That proximity shortens the hop between your storefront's server code and the Storefront API it queries on every page load.
Self-hosted Hydrogen on a distant region adds latency to every server-rendered request. Each one still needs to reach Shopify's API, regardless of where your app server lives. For a storefront rendering every product and collection page server-side, that round-trip adds up across a shopping session.
Deploy previews are a smaller but real point. Every pull request on Oxygen gets an automatic preview URL wired to a real storefront environment with live product and inventory data. Replicating that on a custom AWS pipeline is achievable, but it's extra engineering time billed to your project, not Shopify's.
The honest exception: enterprise teams with existing multi-brand infrastructure on AWS or Vercel, where consolidating hosting under one vendor relationship outweighs Oxygen's convenience. For most DTC and mid-market brands building a single storefront, that trade doesn't pay for itself.
Performance: What Actually Changes
The performance case for Hydrogen on Oxygen rests on two mechanisms, not marketing claims. First, server-side rendering at the edge means the first HTML response reaches the browser from a nearby Cloudflare location rather than a distant origin. That cuts Time to First Byte on cold requests.
Second, a custom-built React frontend ships only the JavaScript your storefront actually needs. A theme accumulated over years of app installs often carries scripts for tools nobody uses anymore, and each one adds parse and execute time on every page.
This isn't automatic, though. A poorly built Hydrogen storefront with unoptimised images, unbounded API waterfalls, or oversized client bundles can perform worse than a well-tuned theme. The framework removes theme bloat as a cause of slow pages, but it doesn't remove the need for careful performance and SEO optimisation during the build.
Setup Considerations That Actually Matter
A few decisions determine whether a Hydrogen-on-Oxygen build goes smoothly or turns into a six-month project. None of these are exotic — they're the same questions we walk clients through before scoping a headless build.
- Third-party app compatibility. Apps that inject Liquid snippets or theme-app-extensions into a standard theme don't work on Hydrogen automatically. You rebuild that functionality as React components calling the app's API directly, or you drop the app.
- Checkout stays hosted by Shopify. Hydrogen storefronts hand off to Shopify's own checkout, unless you're on Shopify Plus with Checkout Extensibility for deeper customisation. Your custom UI covers browsing and cart, not the full purchase path.
- Caching strategy needs deliberate design. Hydrogen exposes sub-request caching controls per API call, but the defaults won't fit every catalog. A 50-SKU boutique and a 5,000-SKU catalog need different cache TTLs on collection queries.
- Content beyond products. Blog posts, landing pages, and marketing content usually need a separate CMS or Shopify's Metaobjects, since Hydrogen's default scaffolding is commerce-first, not content-first.
- Team skill fit. Hydrogen requires React and Remix competency on your team or agency. This isn't a Liquid-theme skill set, and the learning curve is real for teams coming from traditional theme development.
- Migration sequencing. Moving an existing Shopify store to Hydrogen is a frontend rebuild, not a platform migration. It still needs the same care around redirects and tracking continuity that any Shopify migration project requires.
Weighing whether a Hydrogen storefront on Oxygen is the right call for your catalog and team?
Talk to our headless Shopify teamWho Should (and Shouldn't) Use This Stack
Hydrogen and Oxygen make sense when a brand needs storefront experiences a standard Shopify theme can't deliver: complex product configurators, non-standard navigation patterns, or a design system shared across web and native apps. It's also the right fit when a lean, custom-built frontend can shave meaningful weight off page load compared to a theme carrying years of app-injected scripts.
It's the wrong fit for a brand that just wants a fast, well-optimised storefront without full frontend rebuild scope. A well-built custom Shopify theme gets most stores close to Hydrogen's performance and design flexibility, for a fraction of the build and maintenance cost.
Hydrogen's real cost isn't Oxygen hosting — that's free. It's the engineering time to build and maintain a full React application instead of customising Shopify's Online Store 2.0 sections. Budget-wise, expect a Hydrogen build to run meaningfully above a premium custom theme project, reflecting that added scope.
Our Shopify cost calculator gives a ballpark range once you know your catalog size and feature list. If you're weighing this as part of a broader conversion strategy, it's also worth reading how conversion rate optimisation interacts with frontend architecture before you commit either way.
Not sure if you need a full headless rebuild or a faster theme?
Get a free scoping callFrequently Asked Questions
Is Oxygen required to use Hydrogen?
No. Hydrogen produces a standard Remix build that runs on any Node.js-compatible host, including Vercel, AWS, or a self-managed server. Oxygen is Shopify's recommended and cost-included host, but it's a choice, not a requirement.
Does Oxygen cost extra on top of my Shopify plan?
Oxygen is included at no additional charge on Shopify plans that support Hydrogen deployment, starting from Basic Shopify and above. You pay for your existing Shopify subscription; you don't pay a separate hosting bill for Oxygen itself.
Can I use Hydrogen with an existing Shopify theme?
Not directly. Hydrogen replaces your storefront's frontend entirely, so it runs alongside your theme rather than inside it. Many merchants keep their existing theme live during development and cut over to the Hydrogen storefront once it's feature-complete and tested.
Do I lose my installed Shopify apps if I move to Hydrogen?
Apps that rely on injecting code into Liquid theme files stop working as-is, since Hydrogen doesn't render Liquid. Apps with a proper API you can call directly from React components generally still work, just with custom integration code instead of an automatic theme embed.
Is Hydrogen only for large enterprise brands?
No, but it's built for teams with genuine custom frontend requirements and in-house or agency React expertise. Mid-market DTC brands use it successfully when a standard theme can't support their product experience. Smaller catalogs without complex UI needs are usually better served by a custom theme instead.