Deploy your storefront

Ship a Theme with Git-connected deploys or the revenexx CLI, use preview domains, roll back, and activate it per domain in Cockpit.

This tutorial covers shipping a Theme to production: the two deploy paths, the preview domain you test on, how to roll back, and how to activate the Theme on a customer's domain.

This page is for frontend developers ready to ship. You should have a working Theme — see Build your first Theme — and a revenexx account with a tenant.

How a Theme deploys

A Theme is a Storefront on the platform. You connect a repository or push code, the platform builds it (npm install && npm run build, Nuxt SSR output in .output) and creates a deployment — a versioned build you can preview and activate. Each deployment gets a preview URL on the generated *.sites.revenexx.io domain. Activating a deployment on a domain makes it the live one for that domain.

There are two ways to create a deployment. Git-connected is the recommended default; the CLI is useful for a first push and for CI.

Path A — Git-connected deploys

Connect your Theme's repository once, then every push builds and deploys.

  1. Connect the repository to your Storefront in Cockpit → Experience Studio → Sites, in the site's settings, or when you create the Storefront. The full walkthrough, including the install command, build command, and output directory settings, is in Deploy from Git.
  2. Check out your production branch (usually main), commit, and push.
  3. The push triggers a deployment. The platform installs dependencies, runs npm run build, and activates the new build on the production branch.
Ship a change
git checkout main
git add .
git commit -m "Add seasonal hero block"
git push origin main
# → a new deployment builds and activates automatically

Pushing to a branch other than production builds a deployment but does not activate it. You get a preview link to test it first — useful for reviewing a change before it goes live.

Path B — Deploy from the revenexx CLI

The revenexx CLI deploys straight from your terminal. Install it and sign in — there's no project file or init step; the CLI gets its context from your login session and the active tenant.

Set up the CLI
npm install -g @revenexx/cli
revenexx login --token <your-token> --tenant <your-tenant-slug>

From there, create a deployment with the revenexx sites commands — upload your build and activate it:

Deploy the site
revenexx sites create-deployment --site-id <your-site-id> --activate true --code .

The step-by-step walkthrough — finding the site id, deploying from a connected Git repo (sites create-vcs-deployment), and listing or updating deployments — is in Deploy from CLI.

Use the CLI for one-off pushes and CI steps; use Git-connected deploys for the everyday workflow.

Preview before you go live

Every deployment, however you created it, gets a preview URL on the generated *.sites.revenexx.io domain. Open it to confirm the Theme renders in production before you point a real domain at it. Preview links for non-production branches are restricted to members of your tenant, so an unfinished build isn't public. See Previews.

When you preview, check the things that only show up in a real build:

  • The server-rendered pages load and the catalog shell appears in the first byte.
  • Price and stock fill in after paint (the deferred offer from Customize blocks).
  • The tenant's branding is applied with no flash of the default palette.

Activate the Theme per domain

A successful deployment lists your Theme in the Cockpit Theme marketplace. Activation binds an installed Theme to a domain:

  1. In Cockpit → Experience Studio → Marketplace, install the Theme on the tenant if you haven't already; it then appears under Installed Themes.
  2. Activate it for the domain it should serve.

One deployed Theme can serve many tenants — each tenant activates it on its own domain, and the platform resolves the right tenant per request. You don't deploy a separate copy per customer.

Roll back

If a deployment misbehaves, roll back to a previous one. Each deployment is a versioned build, so re-activating an earlier deployment restores it as the live version for the domain without rebuilding. The mechanics — picking a prior deployment and making it active again — are covered in Instant rollbacks.

For a Git-connected Theme you can also roll back by pushing a revert commit, which builds and activates a fresh deployment. Re-activating an existing deployment is faster because it skips the build.

Ship a new version

When you change the Theme's manifest — new blocks, new requirements, a new version — remember that a published Theme version is immutable. Bump version in theme.json (strict semver) before you publish, or the registry rejects the build as already registered. Code-only changes that don't touch the manifest version deploy normally.

Troubleshooting

  • Build fails on deploy but works locally. The platform runs npm install, not a workspace install, so every dependency must resolve from npm. Commit your lockfile.
  • Heavy build times out. A large Theme can exhaust the build container's default memory. Raise Node's heap in your build script: set NODE_OPTIONS=--max-old-space-size=3072 for npm run build.
  • "Already registered" on publish. Bump version in theme.json — published versions are immutable.
  • The domain still serves the old Theme. Confirm the new deployment is the active one for that domain in Cockpit, and that you activated the Theme on the right tenant.

What's next

Was this page helpful?