---
title: Public addresses and custom domains
description: The HTTPS address every web service gets on apps.dekka.cloud, and how to point your own domain at a service.
section: Networking
order: 1
---

Every web service gets an HTTPS address on `apps.dekka.cloud` when it first deploys, and on the Starter and Growth plans you can add your own domains to it. Workers and cron jobs have no public address.

## What is my service's address?

It's the service's name followed by four random characters, such as `web-x2k4.apps.dekka.cloud`. The address stays the same across deploys, and it's shown in the service's details and on the project's **Domains** tab. Your code can read it from `DEKKA_PUBLIC_DOMAIN`.

To stop serving a service at this address, turn off **Public address** in its settings. Its custom domains keep working.

The dashboard's session cookie is pinned to the dashboard's own origin, so code running on an `apps.dekka.cloud` address can't read your Dekka session.

## Add a custom domain

1. Open the project's **Domains** tab, enter the **Domain**, such as `shop.example.com`, pick the **Service** and choose **Add domain**.
2. At your DNS provider, create the two records Dekka shows.
   - A **CNAME** record named `shop.example.com` with the service's address as its value, such as `web-x2k4.apps.dekka.cloud`, which sends traffic to the service.
   - A **TXT** record named `_dekka-challenge.shop.example.com` with the value Dekka shows, which starts `dekka-verify=` and proves you control the domain.
3. Choose **Check DNS**.

Many DNS providers don't allow a CNAME on a bare domain such as `example.com`, so use a subdomain such as `www`, or a provider that flattens CNAME records at the root.

```bash tab="cURL"
curl https://api.dekka.cloud/v1/resources/$SERVICE_ID/domains \
  -H "Authorization: Bearer $DEKKA_API_KEY" \
  --json '{ "hostname": "shop.example.com" }'

curl -X POST https://api.dekka.cloud/v1/domains/$DOMAIN_ID/verify \
  -H "Authorization: Bearer $DEKKA_API_KEY"
```

## How does verification work?

**Check DNS** looks up the TXT record. When it holds the right value, the domain becomes **Verified**, Dekka starts routing it to the service and asks for a certificate. When it doesn't, the domain shows **DNS doesn't match** with the reason, and you can fix the record and check again. DNS changes can take a few minutes to arrive.

Dekka also checks the CNAME and tells you when it "doesn't point at Dekka yet". The domain can verify without it, but traffic won't reach the service until it points at the service's address.

## Certificate states

| Shown as | Certificate status | What it means |
| --- | --- | --- |
| Certificate after verification | `pending` | The domain hasn't been verified yet |
| Issuing certificate | `issuing` | The domain is verified and the certificate is on its way |
| HTTPS ready | `active` | The domain serves HTTPS |
| Certificate failed | `failed` | The certificate couldn't be issued |

## Limits

Custom domains need the Starter or Growth plan, and adding one on Free answers 403 `entitlement_exceeded`. A web service can have up to 20, and names under `dekka.cloud` or `dekka.internal` are reserved. A domain can belong to only one service, and removing it stops routing it straight away.