Custom domain onboarding checklist
What a platform team checks before its customers connect their own domains, with the docs page for each step.
For product managers and platform engineers planning a custom domain launch.
Before you build
Three choices that shape everything after them.
| Check | What good looks like | Docs |
|---|---|---|
| Decide where domains point | Customer domains point at the CustomDomain™ edge, which issues certificates on Growth and up, or at your own servers, which serve TLS. | Where domains point |
| Run the flow in test mode | A test mode application connects made up .test names, goes live on a simulated clock and sends the same webhooks. | Test mode |
| Pick your way in | The console for your own domains, the API server to server, the widget inside your product, or MCP for agents. | Which path are you on? |
While your customer connects
What your customer meets, from typing the domain to live.
| Check | What good looks like | Docs |
|---|---|---|
| Detect the DNS provider | The domain's nameservers name its DNS provider, so your customer never picks one from a list. | Connection paths by provider |
| Write records where you can | Where the provider allows it, a sign-in, Domain Connect or an API key writes the records. Elsewhere your customer copies the exact rows. | How the connect flow works |
| Catch copy mistakes | A full hostname typed into the Name field, a proxy left on or an old record in place is caught and named. | Troubleshooting |
| Handle root domains | A root like acme.com gets an ALIAS-style record or A records, by provider, with www offered as the fallback. | Root domains (apex) |
| Show live status | Your customer sees pending, propagating, live or failed, updated as each check runs. | Apply records and go live |
| Name the record at fault | A failed setup names the record and its fix, through the connection's error code, never just that something went wrong. | Connections |
| Never show live too early | A domain reads pending, propagating or failed until every record resolves, and HTTPS starts only after live. | Which path are you on? |
Before you launch
What your support team and your backend need on day one.
| Check | What good looks like | Docs |
|---|---|---|
| Check the certificate path | On Growth and up, certificates issue on the first HTTPS request after live. Any CAA record must allow Let's Encrypt. | Certificates |
| Subscribe to webhooks | Your backend hears connection.live and connection.failed, and checks each signature. | Webhook events and delivery |
| Write the customer help text | Help text tells your customer what they will actually do: sign in, approve, paste a key or copy records. | Setup types and the ask gate |
After launch
Domains keep changing after they go live.
| Check | What good looks like | Docs |
|---|---|---|
| Re-check records on a schedule | Live domains are checked against their records, and a missing or changed record is found and named. | Monitoring and services |
| Plan for removal | Removing a domain stops serving it, and you choose whether its DNS records come out or stay. | Removing a domain |
Put your customers on their own domains.
Your first ten domains connect free. No card needed to sign up.