Domains

You prove you own a domain for the whole workspace with one TXT record, which you keep in place. Your web apps and Kubernetes clusters can then serve hostnames under it, with certificates the platform issues and renews. Domains are in the dashboard under Domains.

Verify a domain

1. Choose Add domain and enter the domain, such as example.com: no https:// and no path.
2. On its row, choose Set up. It shows the record to add:

3. Add that record at your DNS provider, and leave it there. It sits under a name of its own, so it changes nothing about where your domain points, and other TXT records at that name do not get in the way.

The platform looks for the record right away, then again after 1 minute, 5 minutes, 15 minutes, 1 hour and 6 hours, and then every 12 hours. Check now, in the same dialog, looks again at once, at most every 30 seconds. After twelve looks without finding it, about three days, it stops and the domain shows Check failed: fix the record, then choose Check now.

While the domain waits, its row says why the last check failed. The domain does not resolve usually means the record is not published yet, or not visible yet.

• You can also verify a subdomain on its own, such as shop.example.com, with its record at _sahabti-verify.shop.example.com: useful when you control only that part of the domain.
• Wildcards, such as *.example.com, are not accepted, and neither are the platform's own domains.
• A domain can be verified by one workspace only.
• A workspace holds up to 10 domains, in any status.
• An internationalised domain is shown in its xn-- form.

To remove a domain, choose Remove in its row's menu. A domain with hostnames still bound under it cannot be removed: remove them from their web apps or clusters first.

Keep the record in place

A domain can change hands, so the platform checks a verified domain's record again every day. When a check does not find it:

• The domain's row, and a notice at the top of the Domains page, ask you to re-add it and say when the hostnames under the domain will be suspended.
• The workspace's owners and admins get an email with the record and that date.
• The platform looks for the record every hour, and Check now, in the domain's Set up, looks at once. Once the record is found again, the domain carries on as before.

If the record is still missing three days after the first check that missed it, the domain is no longer verified: the hostnames bound under it are suspended, and another workspace may verify the domain. The domain goes back to Awaiting DNS and to the checks above. Once you re-add the record and the domain is verified again, its hostnames are served again, unless another workspace has proven them first in the meantime.

A domain verified before these daily checks began gets 30 days instead of three the first time its record goes missing.

Serve a web app on your domain

Open the web app, go to its Domains tab and choose Add domain. Enter any hostname you own: the domain itself, such as example.com, a www name, or another subdomain.

If the workspace does not have the hostname's domain yet, adding it also claims that domain for the workspace, so it appears on the Domains page. The hostname's Set up then lists what to add at your DNS provider:

1. Prove you own the domain: the TXT record above, shown until the domain is verified. One record covers every hostname under the domain.
2. Point the hostname at the platform: a CNAME record from the hostname to the target shown, apps.sahabti.app.

A CNAME on the domain itself, such as example.com, needs a DNS provider that allows one at the root; a subdomain works with every provider. Once the domain is verified and the CNAME is live, the certificate is issued on its own, usually within a few minutes:

A hostname whose domain is no longer verified goes back to Awaiting ownership, and its row says it is suspended.

The app's default URL keeps working beside its own hostnames, and Visit opens the first hostname you added that is active. An app takes up to 10 hostnames, and wildcards are not supported.

Removing a hostname stops it routing to the app. The domain stays on the workspace's Domains page.

Kubernetes clusters

A cluster's managed gateway can serve a hostname such as shop.example.com with nothing but a CNAME record pointing at the cluster's own hostname, <cluster>.sahabti.app, and nothing to verify on this page: see Your own domain. A root domain such as example.com cannot hold a CNAME record, so you verify it here first and then bind it to the cluster, as the same guide describes.

Instances and load balancers

An instance's Domain tab is only for instance types that serve a website, and none of the types you can create today has one: connect to managed services, virtual machines and game servers with the hostname their Overview shows. A load balancer can be reached under your own domain with a CNAME record to its DNS name: see Where clients connect.

One hostname, one place

A hostname can be served by only one web app, cluster or instance on the whole platform, and it goes to the first workspace that proves it. Adding a hostname that another one already holds is refused with That name is already in use by another workspace or resource. A hostname that another workspace has added but not proven never blocks you: whichever workspace proves it first gets it, and the other's shows Taken by another workspace in a web app, or Not allowed in a cluster.

Who can do what

A developer can add a web app hostname only under a domain the workspace already has: adding a new domain to the workspace is for owners and admins.

From the API

Workspace domains are under /v1/domains, with POST /v1/domains/{id}/verify for Check now, and a web app's hostnames under /v1/apps/{id}/domains. A domain whose record a daily check missed carries lapsedAt, and suspendsAt while it is still verified, and each web app hostname's issue says what is wrong, if anything.