Build and deploy

Getting a storefront onto the platform — build configuration, compute specifications, environment variables, and the four ways to create a deployment.

You don't pick a host. A storefront deploys onto the platform itself as a site: you connect a Git repository or push with the CLI, the platform installs dependencies, runs your build, and creates a versioned deployment.

Exactly one deployment is active at a time, and that's what your domains serve. Builds accumulate, and switching which one is live is a pointer change rather than a rebuild — which is what makes rollbacks instant.

Three ways to create a deployment

In rough order of how often you'll use them:

WayWhen
From GitThe default for day-to-day work. Connect a repository once; every push to the production branch builds and activates, and every other branch gets a preview.
From the CLIA first push, a CI step, or a project whose repository isn't connected yet. revenexx deploy theme . does the whole pipeline in one command.
By uploadA one-shot deploy, or a build produced by a pipeline that lives somewhere else. A .tar.gz of your build output.

What belongs to the site, not the repository

This trips people up once and then never again. The install command, the build command, the output directory, the framework, the adapter, the compute specifications and the environment variables are all properties of the site — not files in your repository.

Two consequences:

  • They apply from the next deployment onward. Changing a build setting does not change the running build. Create a new deployment.
  • They're the same wherever you set them. Cockpit, the CLI and the API write the same fields.

A theme's theme.json#site block declares the defaults for these, which is how a scaffolded theme deploys correctly without you configuring anything — see Theme anatomy.

Where to go next