Deploy a Catalyst Storefront

Catalyst is a standard Next.js application, deployable anywhere Next.js runs. BigCommerce documents and tests two deployment paths:

• Native Hosting (recommended): BigCommerce’s own hosting infrastructure, deployed entirely through the Catalyst CLI. Currently in closed beta.
• Vercel: a third-party Next.js hosting platform, with a separate Vercel account.

If neither fits your needs, you can deploy to any other provider that meets the Next.js requirements below, following that provider’s own Next.js deployment guidance.

Choose a hosting platform

Native Hosting is the recommended path for new Catalyst storefronts. Choose Vercel if you’re waiting on Native Hosting beta access, need a Vercel-specific feature, or already host other projects on Vercel. For a feature-by-feature comparison, see Choosing a Hosting Platform.

You can create a project that’s ready for Native Hosting from the start with pnpm create @bigcommerce/catalyst@latest --hosting commerce, or opt in later from an existing project. See Native Hosting: Getting Started.

Other hosting providers

Any provider you choose must support the following Next.js capabilities that Catalyst relies on:

• On-demand server rendering. Catalyst renders storefront routes when they’re requested rather than generating them at build time, so the host must run a Next.js server. Static exports aren’t supported.
• Data Cache. Catalyst caches GraphQL Storefront API responses for guest shoppers with time-based revalidation (next: { revalidate }) and on-demand revalidation (revalidateTag).
• Proxy (proxy.ts, which replaced Middleware in Next.js 16). Catalyst’s routing, authentication, localization, and UCP handling run in its proxy chain. See Proxy.

Consult the Next.js documentation or your hosting provider’s documentation for guidance on deploying to your provider of choice.

Environment variables

Regardless of where or how you deploy your Catalyst application, you’ll need an updated set of environment variables. Assuming you’ve already run your application locally (see Run locally for One-Click Catalyst projects, or CLI Installation), you can reuse most of the environment variables defined in your .env.local file.

However, a few environment variables need to be updated. Check the documentation for each one on how to update it:

• AUTH_SECRET
• BIGCOMMERCE_STOREFRONT_TOKEN
• MAKESWIFT_SITE_API_KEY

For the full list, see the Environment Variables reference.

Redirected Checkout

Catalyst uses Redirected Checkout out of the box. When shoppers are ready to complete a purchase, they’re redirected to BigCommerce’s hosted checkout.

Here’s how it works:

• A channel site’s checkout URL determines which URL loads when shoppers are redirected to checkout.
• DNS for the checkout domain can point at the Catalyst channel, for example with a CNAME record pointed to store-{store_hash}-{channel_id}.mybigcommerce.com.
• When the checkout domain points at the Catalyst channel this way, Stencil serves the checkout, but in the context of the Catalyst channel rather than the default channel (channel 1).

For example:

• mystore.com points at your hosted Catalyst storefront.
• checkout.mystore.com is a CNAME pointed at BigCommerce on the Catalyst channel.

A channel created through One-Click Catalyst is already set up this way. To set the checkout URL yourself, see Manually Create Catalyst Channel, or Checkout Domains on Native Hosting.

Launch a single storefront

A single Catalyst storefront doesn’t need Multi-Storefront (MSF) enabled. To launch one without MSF:

1. Leave the default channel (channel 1) in Prelaunch status.
2. Create the Catalyst storefront channel with One-Click Catalyst or CLI Installation.
3. Set channel 1 to Inactive.
4. Once Catalyst is deployed to your hosting provider, set the channel site’s main and checkout URLs as described above, then set the Catalyst channel to Active.

This setup uses a single storefront seat for licensing and pricing.