Get started with domains

Your own domain can serve your web apps, your Kubernetes clusters and your load balancers, each in its own way. A web app takes hostnames under a domain you verify once for the whole workspace, with a TXT record you keep in place. A Kubernetes cluster needs no verification: a CNAME record that points your hostname at the cluster is the proof. The platform issues and renews the certificates for both.

Before you start

• A domain you control at your DNS provider.
• To add a domain to the workspace: the Owner or Admin role. Developers can then add hostnames under it to web apps.

Serve a web app on your domain

1. Open the web app's Domains and choose Add domain. Enter the hostname, such as www.example.com. If the workspace does not have its domain yet, this adds it to the workspace's Domains page too.
2. Open the hostname's Set up. It lists two records:

3. Add both at your DNS provider, and keep the TXT record in place. If your provider adds your domain to the end of a name for you, enter only the part before it, such as _sahabti-verify.

The platform looks for the TXT record at once, then again on a schedule; Check now, in the domain's Set up on the Domains page, looks again straight away. The domain moves from Awaiting DNS to Verified, and the hostname from Awaiting ownership to Certificate pending to Active, usually within a few minutes of both records being live.

A CNAME on the domain itself, such as example.com, needs a DNS provider that allows one at the root; a subdomain such as www works everywhere.

Point a hostname at a Kubernetes cluster

Clusters do not use the Domains page. In the cluster's Services & routes, under Managed gateway → Use your own domain, enter shop.example.com and select Add hostname, then create the CNAME record the console shows:

Name the hostname in a route, and it moves from Waiting for DNS to Issuing certificate to Live. A root domain cannot hold a CNAME record, so serve www.example.com instead. See Get started with Kubernetes.

Reach a load balancer by name

Point your hostname at the load balancer's DNS name, shown on its Overview, with a CNAME record. Clients still connect with the listener's port, such as tcp.example.com:40006. See Load balancers.

With PromptOps

In a workspace with PromptOps on, ask in the chat. It asks before it changes anything:

• "Add shop.example.com to the shop cluster's gateway, and tell me which CNAME record to create."
• "Which hostnames of the shop cluster are not live yet, and why?"

Adding a domain to the workspace and a hostname to a web app stay in the console.

With the API or MCP

Create an API token with the domain actions, and save the domain as domain.json:

{
  "orgId": "<workspace id>",
  "name": "example.com"
}

curl -X POST https://api.sahabti.com/v1/domains \
  -H "x-api-key: $SAHABTI_TOKEN" \
  -H "Content-Type: application/json" \
  -d @domain.json

The answer carries the TXT record to add. POST /v1/domains/{id}/verify is Check now, and a web app's hostnames are under /v1/apps/{id}/domains. Over MCP, add_kubernetes_gateway_cname adds a hostname to a cluster.

What it costs

Domains, hostnames and their certificates cost nothing. A workspace holds up to 10 domains, and a web app up to 10 hostnames.

First checks

• On Domains, the domain shows Verified.
• Each web app hostname shows Active, and opens over HTTPS.
• Each cluster hostname shows Live in Services & routes.
• dig +short CNAME www.example.com returns the target you set.

Next steps

• Domains: keeping the record in place, statuses and who can do what
• Expose HTTP services: your own domain on a cluster, in full
• Web apps: the app the hostname serves