Documentation/Deployment/Custom Domains
Custom Domains
Pointing your own domain at a deployed Supero application is not self-service today. This page explains what a published app's address actually is, what the custom-domain fields in settings are really for, and how to arrange a branded address.
The Short Answer
You cannot point your own domain at a deployed Supero application yourself. There is no self-service flow for it on any deployment target — not on Supero Cloud, not on an app deployed into your own AWS account, and not on one deployed into your own GCP project. There is no DNS automation, no certificate provisioning, and no domain-mapping step anywhere in the deploy path. The address you get is the address the platform generates.
⚠️ Do not plan a launch around a branded URL without asking first
If a customer-facing domain is a requirement for your launch, raise it with [email protected] before you commit to a date. A branded address is a manual arrangement, not a setting you can turn on, and it is not something you can unblock yourself at the last minute.
What a Published App's URL Actually Is
A published Supero Cloud app is served on a subdomain of supero.live. The subdomain is derived from your domain name and project name, so it is stable across redeploys of the same project and you can share it, but you do not choose it:
text
https://live-{domain}-{project}.supero.liveRouting for supero.live is a fixed set of rules in front of the platform. It matches subdomains of supero.live and nothing else — there is no rule that accepts an arbitrary hostname, and no way to add one from the product.
| Deployment target | Address you get | Who issues it |
|---|---|---|
| Supero Cloud (Go Live) | https://live-{domain}-{project}.supero.live | Supero |
| Your own AWS account | The hostname the AWS service assigns to the deployed service | AWS |
| Your own GCP project | The hostname Cloud Run assigns to the deployed service | |
| On-premise | Whatever host and port you run the app on | You |
ℹ️ On-premise and your own cloud are the exception
When the app runs on infrastructure you control, the hostname in front of it is yours to decide. On-premise, you put the app behind whatever reverse proxy and certificate you already use. In your own AWS or GCP account, nothing stops you putting your own load balancer or CDN in front of the deployed service and terminating TLS there — but that is your infrastructure, and Supero neither creates it nor knows about it. Supero Cloud is the case with no self-service option at all.
The Custom-Domain Fields in Settings
There are two places in the product where you can type a domain name, and finding one of them is the usual reason people believe custom domains are supported. They are not routing controls. They are text fields that record a value for the team to act on, and their own on-screen help says so.
| Where you found it | What it stores | What it does not do |
|---|---|---|
| Workspace settings — a custom domain on your domain (workspace) | A single hostname, stored against your workspace. Its help text tells you to contact support to configure DNS. | It does not create a DNS record, request a certificate, or change where any deployed app answers. |
| Tenant settings — custom domains on a tenant | A list of hostnames, stored against an individual tenant. Its help text tells you to point a DNS CNAME at your platform host yourself. | It does not create the CNAME for you, and it does not route a deployed app. |
🚨 Saving a value in these fields changes nothing about your app's address
Both fields accept whatever you type and save successfully. Neither one triggers any provisioning. If you enter a domain, wait, and then find the app is still only reachable at its generated address, nothing has failed — that is the expected behaviour. Treat a saved value as a note for the team, not as a configuration that has taken effect.
⚠️ Two things here will mislead you
A Visit link appears next to the workspace field once you save a value, pointing at the domain you typed. It is built from the text you entered, not from anything that was configured, so it will not resolve unless you have separately arranged for that hostname to serve something. Separately, the tenant field describes itself as being used to resolve a tenant from the request host — that is not implemented. Tenant resolution does not consult these values, so adding a hostname to a tenant does not make requests to that hostname land in that tenant.
If You See a Custom-Domain Add-On in Billing
A custom-domain line item appears in the add-on catalog, priced per project per month, and its description offers to serve a project on your own domain with managed SSL. Read this page as the correction to that description: purchasing the add-on does not turn on a self-service flow, and no certificate is provisioned for you as a result of the purchase. Nothing in the product changes when it is added to your plan.
🚨 Agree what you are buying before you buy it
If a branded address matters to you, mail [email protected] first and get agreement in writing on what will be set up, by whom, and by when. Do not add the add-on and wait for something to happen. We would rather correct our own catalogue on this page than have you pay for a capability you cannot use. If you have already been billed for it without an arrangement in place, write to [email protected] and say so.
What To Do Instead
Mail [email protected] and ask for a branded address to be arranged. Including these five things in the first mail saves a round trip:
- •The domain name you want to use, and whether you control its DNS.
- •Your Supero domain (workspace) name and the project name of the app.
- •The generated address the app currently answers on.
- •Which target it is deployed to — Supero Cloud, your own AWS, your own GCP, or on-premise.
- •Your launch date, if there is one.
We do not publish a timeline for self-service custom domains, and this page will say so until there is one to publish. If a branded address is a hard requirement, ask before you build, not after.
On this page