Domains

Every storefront gets a revenexx-generated domain the moment it deploys, and you can add your own domains on top. revenexx issues and renews the TLS certificate for each one automatically, so both the generated and the custom domains are safe to use in production.

Generated domains

Two names arrive without you doing anything, and they are for different jobs.

The tenant domain, <tenant>.revenexx.cloud, is created with the tenant itself. It is pointed at the edge and registered with the mail service, so a brand-new tenant can serve assets under /cdn/ and send mail before anyone has opened a DNS panel. It is not tied to a deployment — it exists even if no storefront has shipped yet.

A site's generated hostname under sites.revenexx.io arrives per site, as soon as it has a successful deployment. It works immediately, needs no DNS work from you, and is the right thing to test a storefront against before a real domain is involved.

Alongside it, every deployment gets its own preview hostnames — a unique one, one keyed to the commit, and one keyed to the Git branch. Those are covered in Previews.

Add a custom domain

A custom domain needs exactly one record in your zone, and which record depends on what the domain is for.

The record name is the domain you are adding — not _something, not a subdomain of it. Adding shop.example.com means one record named shop.example.com.

Copy the exact value from Cockpit. When you add a domain under Experience Studio → Domains, the domain's DNS & TLS view shows the record you need — type, name, value, and TTL — with a copy button. That view is authoritative: the edge hostname can change, and Cockpit always shows the current one. For orientation, a storefront domain currently looks like this:

shop.example.com.   3600   IN   CNAME   edge.revenexx.com.

Once the record resolves, trigger verification from the same view. Propagation is usually well under a minute if your TTLs are sane; a stale, long-TTL record at your provider is the usual reason it takes longer.

What revenexx does not need

This is worth stating plainly, because it is the part most likely to be assumed wrong:

• No delegation. You do not hand your zone, or its authoritative servers, over to revenexx. The zone stays where it is, under your control.
• No TXT record. Verification is done by resolving the one record above. There is no _acme-challenge, no verification token to publish.
• Nothing else in your zone is touched. Your MX records, your mail authentication, your other subdomains — all untouched, because you are adding one record rather than handing over the zone.

Accepted record types for a custom domain are CNAME, A, and AAAA. A CNAME is the normal case; A/AAAA exist for the situations below.

Apex domains

A CNAME is illegal at a zone apex, so example.com cannot use one. Two options:

1. Use your provider's apex flattening. Many providers offer ALIAS, ANAME, or "CNAME flattening" at the apex — a record that behaves like a CNAME but answers with an address. Point it at the same edge hostname Cockpit shows you.
2. Make the apex a redirect. Add www.example.com as the storefront domain with a CNAME, then add example.com as a redirect domain to it with an A record. This is the common pattern and works with every DNS provider.

If your zone publishes CAA records

revenexx does not ask you to add a CAA record. But if your zone already has CAA records — some registrars add them by default — they must permit Let's Encrypt, or certificate issuance will fail after your domain otherwise verifies correctly:

example.com.   3600   IN   CAA   0 issue "letsencrypt.org"

If you publish no CAA records at all, there is nothing to do: an absent CAA record set permits any certificate authority.

TLS certificates

Certificates are issued automatically from Let's Encrypt once a domain verifies, and renewed automatically well before expiry. You do not request, install, or rotate anything. If a customer has a certificate they must use — an EV certificate, or one from a CA their security policy mandates — it can be uploaded instead, but the automatic path is the default and the one to prefer.

What a domain can point at

A domain that serves a storefront resolves to one of these:

• The active deployment. The domain always serves whatever deployment is currently active. This is what production domains use, and it is what makes rollbacks instant — activating a different deployment changes what the domain serves without any DNS change.
• A specific Git branch. The domain serves the latest successful build from one branch, which is how a staging domain like staging.example.com stays pinned to a staging branch across deployments.
• A redirect. The domain answers with a permanent redirect to another URL. Path and query are preserved, so example.com/products?id=123 lands on www.example.com/products?id=123.

Reserved prefixes

The prefixes commit- and branch- are reserved on the generated sites domain, because that is where deployment preview hostnames live. A custom domain cannot start with either.

Troubleshooting

• Verification fails but the record looks right. Compare the value character for character against the DNS & TLS view — the diagnostics there show what was expected and what actually resolved. A trailing-dot difference is fine; a different hostname is not.
• Verification passes, HTTPS fails. Check for pre-existing CAA records in the zone (see above).
• The apex won't take a CNAME. That is DNS behaving correctly, not a revenexx limitation. Use apex flattening or the redirect pattern.
• The domain serves an old build. DNS is not the problem — the site's active deployment is. See Deployments.

Related

• Previews — the per-deployment hostnames and how to protect them
• Instant rollbacks — changing what a domain serves without touching DNS
• Deploy your storefront — the end-to-end tutorial, including activating a theme per domain