Run it in production

Operating a live storefront — deployment statuses, preview hosts, instant rollbacks, custom domains and TLS, request logs, and publishing a theme to the marketplace.

Ship and verify

Deployments

The five statuses, build logs, and why "active" is a pointer rather than a status.

Previews

The three hostnames every deployment gets, and how to protect them before a build goes live.

Instant rollbacks

Activate any ready deployment — no rebuild, no DNS change, no downtime.

Operate

Domains

One CNAME, automatic TLS, apex handling, and what revenexx does not need from your zone.

Logs

Request logs from the running storefront, build logs on the deployment, and what to keep out of both.

Publishing a theme

Registry registration, the marketplace, installing on a tenant, and activating per domain.

Once a build exists, running it is mostly about four ideas.

A deployment is a versioned build, and one of them is active. Builds accumulate; the active one is what your domains serve. That separation is why the rest of this group is simple.

Every deployment is reachable before it's live. Three generated hostnames per deployment, so you verify a real build in a real environment while production still serves the previous one.

Going back is a pointer change. Any ready deployment can be activated again — no rebuild, no DNS change, no downtime.

A domain is one DNS record. One CNAME named as the domain, pointing at the value Cockpit shows you. TLS is issued and renewed automatically.

Where to go next

  • Deployments — statuses, build logs, and redeploying after a configuration change.
  • Previews — the unique, commit and branch hostnames, and access control.
  • Instant rollbacks — and what a rollback does not revert.
  • Domains — custom domains, apex handling, automatic TLS.
  • Logs — request logs, and why you should not assume a retention window.
  • Publishing a theme — from a ready deployment to a theme live on a customer's domain.