Build your storefront
Create a storefront
The two ways to get a running shop, a managed theme or your own deployed site, and how to pick one.
There are two routes to a running storefront, and the choice decides who maintains it for the next five years. Make it deliberately.
Before you begin. You need an active project selected in the top bar, and,
before anything goes live, a domain you control. You can build and preview
without a custom domain, but you cannot activate a theme without a verified one.
Two routes
| Managed theme | Self-hosted site | |
|---|---|---|
| What it is | A theme you install for the tenant and activate on a domain | Your own storefront application, deployed from Git or an upload |
| Runs on | The shared platform runtime | Your site's own build and runtime |
| Who changes the templates | The theme vendor; you change its settings | Your developers |
| Time to something live | Same day | A project |
| Right when | You want a shop, not a codebase | The storefront is bespoke, or your team already owns a frontend |
Most companies should start with a managed theme. Choose a self-hosted site when you have a frontend team, a design that no theme will carry, or an existing storefront you are migrating rather than replacing.
Route A: install a theme
- Go to Experience Studio › Marketplace.
- Open a theme to read its listing: publisher, version, engine, languages, features, pricing and the permissions requested. A theme runs against your tenant's data; read that list rather than clicking past it.
- Select Install. The theme is now installed for the tenant but serves nothing yet.
- Add and verify a domain. See Domains and going live. A theme cannot be activated without a verified domain.
- In Experience Studio › Installed Themes, use Activate on domain and pick the domain it should serve.
- Configure it under the theme's Settings tab. See Themes and branding.
Route B: deploy your own site
- Go to Experience Studio › Sites and select Create site.
- Choose a source:
- From Git repository: connect GitHub, pick a repository and a production branch. Every push to that branch triggers a deployment.
- Manual upload: drop a
.tar.gzof your build output. A one-shot deploy, with no automatic redeploys.
- For Git: install the Revenexx GitHub App on the organisation that owns the repository, pick the repo, then the production branch. The framework is detected for you; override it if the detection is wrong. Set the root directory if the site is not at the repository root.
- Review the configuration: install command, build command, output directory,
and the environment variables found in the repository's
.envkeys. Environment variables reach both the build and the runtime, so mark secrets as secret. - Optionally set a custom Site ID (letters, digits, period, hyphen and underscore, up to 36 characters). The platform generates one if you leave it empty.
- Deploy. The first build appears in the site's Deployments list.
- Point a domain at it: in Experience Studio › Domains, open the domain, choose Self-hosted storefront under Routing, pick the site, and select Apply routing.
What to check
Open Experience Studio › Sites. The row for your storefront shows its Status; it should read as built rather than failed. Then open the site and check the Overview tab:
- Live reads Yes, not Out of date. Out of date means a newer deployment exists but the older one is still the active one.
- The active deployment is the one you expect, with a sensible build size and duration.
If the build failed, open the deployment row and read its build log. Build failures at this stage are almost always the install or build command, or a missing environment variable, the same failure you would get locally.
For a managed theme, check Installed Themes: the Live on column should name your domain.
When it does not work
- "No verified domains" when activating a theme: the domain exists but its DNS has not verified yet. Finish Domains and going live first.
- The site builds but the domain shows nothing: routing was never applied. A domain with Not routed under Serving is doing exactly that.
- Pushes do not trigger a build: the push went to a branch other than the configured production branch, or the GitHub App is installed on a different organisation than the one that owns the repository.
Deleting a storefront deletes all of its deployments permanently, including the
build history you would need to roll back. Remove the domain routing first and
confirm nothing is served by it before you delete anything.
Next
- Themes and branding: make it look like your company.
- Domains and going live: DNS, TLS and the launch.