Deploy Hydrogen to Oxygen From a Development Store

Shopify removed a real source of friction from early Hydrogen work: as of August 3, 2026, a development store can deploy a Hydrogen storefront to Oxygen without moving to a paid plan first.

The important limit is just as clear. Development stores do not include public environments. Every Oxygen deployment URL created from one requires a store login.

That makes the new workflow useful for an authenticated proof of concept, architecture validation, and runtime QA. It does not create a public demo, a production environment, or proof that the storefront is ready for customers.

What changed

Before this update, using Oxygen required the store to be on a paid Shopify plan. A team that wanted to prove the Shopify-native hosting path early had to activate billing or use another host for the prototype.

Now the supported stack can be tested earlier:

• A Hydrogen project can connect to a development store.
• The storefront can deploy to Oxygen.
• The deployment can use Oxygen environment variables and runtime behavior.
• Developers and authorized store users can inspect the result after signing in.

The hosting cost barrier moved. The public-access boundary did not.

What this deployment can and cannot prove

This distinction keeps the prototype honest. The development-store deployment is an engineering environment, not a customer-facing launch.

How to deploy Hydrogen to Oxygen from a development store

1. Start with a real development store

Create or select the Shopify development store that will own the test storefront. Use representative products, collections, markets, and customer-account settings when those areas affect the architecture decision.

Do not fill the store with invented performance proof or fake merchant data. The prototype needs enough realistic structure to expose integration risk, not enough decoration to look like a finished brand launch.

2. Install the Hydrogen channel

Install the Hydrogen sales channel in that development store, then create or select the Hydrogen storefront. The channel is the Shopify-side control surface for Oxygen, storefront credentials, deployments, environments, and logs.

For a feasibility prototype, use current Hydrogen unless the explicit purpose is to test the separate Hydrogen developer preview. Shopify still describes current Hydrogen with React Router as the fully supported path.

3. Create the project and prove it locally

The current Hydrogen quickstart remains the shortest supported starting point:

npm create @shopify/hydrogen@latest oxygen-dev-store-lab
cd oxygen-dev-store-lab
npm install
npm run dev

Before deploying, prove the smallest commerce loop locally:

1. A collection loads products from the intended store.
2. A product page resolves a real variant.
3. Adding and updating a cart works.
4. Checkout handoff reaches the correct Shopify checkout.
5. Missing routes return the expected response.

A local success is not an Oxygen success, but it removes basic application errors before the runtime check.

4. Connect GitHub or use the Hydrogen CLI

Shopify recommends GitHub-based continuous deployment for Hydrogen projects. Connecting the repository creates a repeatable deployment path for branches and commits.

For a manual validation, the Hydrogen CLI can build, upload, deploy, and return the unique deployment URL:

npx shopify hydrogen deploy

Follow the CLI prompts to authenticate, select the development store, and select the Hydrogen storefront. Do not put Storefront API tokens or other secrets in the repository.

5. Verify the environment variables

Oxygen automatically provides the required Shopify variables when the storefront is created. The important group includes the store domain, public and private Storefront API tokens, Customer Account API values, storefront ID, and SESSION_SECRET.

Add only the extra variables the prototype needs, such as a CMS or search endpoint. Keep server-only tokens secret and scoped to the correct environment.

Oxygen deployments are immutable snapshots. If an environment variable changes, create a new deployment or redeploy the relevant environment before expecting the change to appear.

6. Open the deployment as an authorized store user

The development-store URL will require a Shopify store login. That is expected behavior, not a deployment failure.

Private deployment authentication also adds request overhead, so do not use this URL as a clean public performance benchmark. Use it to compare application behavior, request shape, caching decisions, and Oxygen compatibility under the environment Shopify provides.

The prototype QA checklist

Run the same small checklist after every meaningful deployment:

• Confirm the deployed commit and environment.
• Load homepage, collection, product, search, cart, and a deliberate 404.
• Check variant selection and cart persistence after refresh.
• Confirm checkout handoff uses the intended store and market.
• Test logged-in customer behavior if the scope includes customer accounts.
• Confirm server-only credentials never appear in the browser.
• Inspect Oxygen logs for runtime errors and failed upstream requests.
• Verify cache behavior on catalog queries that are meant to be cached.
• Record the deployment URL, result, and unresolved risks.

The useful deliverable is not just a URL. It is a short evidence set showing which parts of the proposed architecture work and which decisions remain open.

What not to promise from this environment

A development-store Oxygen deployment does not prove:

• Anonymous stakeholder access or a public sales demo.
• Production domain, DNS, redirect, canonical, robots, or sitemap behavior.
• Real traffic performance without the login boundary.
• Production analytics, consent, app callbacks, or customer communication.
• A safe Liquid-to-Hydrogen migration plan.
• That Hydrogen is the right commercial decision for the store.

Those are later gates. They need a production-like environment, a real migration inventory, or both.

How to move from prototype to a production decision

End the prototype with three possible outcomes.

Proceed with Hydrogen when the custom storefront solves a defined business problem, the important integrations work, and the operating cost is understood.

Narrow the scope when the runtime is viable but customer accounts, search, CMS, analytics, or app replacements still need separate proof.

Stay on Liquid for now when the main problem can be solved safely in the theme, the prototype exposes too much operational overhead, or the business case is still weak.

That is why the new development-store access matters. It lets the hosting and integration questions be answered before billing pressure turns an experiment into an assumed migration.

The practical takeaway

Use Oxygen on a development store as an authenticated technical checkpoint.

Prove the build, Shopify connection, cart, checkout handoff, environment variables, logs, and the riskiest integration. Then carry only the verified parts into production planning.

That evidence can also prevent an unnecessary rebuild when the prototype shows that the existing theme remains the safer business and operating choice.

If someone needs a public demo, production-domain QA, or an anonymous performance test, move to an environment designed for that purpose instead of treating the login-protected development deployment as something it is not.