CUSTOM DOMAIN
When you let a customer put your product on their own domain, two very different jobs hide behind that single feature. The first is getting DNS pointed correctly and proving the customer actually controls the name. The second is answering HTTPS requests for that name the instant they start arriving. Most teams treat this as one big mystery, ship a wall of setup instructions, and then watch a large share of paying customers stall out. About half of them never finish the DNS step. This post walks through what custom-domain onboarding actually does, plane by plane, and why a one-click connection removes the part that people fail at.
Two planes, not one feature
It helps to split the work into a connect plane and an edge plane. The connect plane deals with configuration and identity: it decides which DNS records the domain needs, gets them in place, and proves the customer owns the name before anything goes live. The edge plane deals with traffic: it terminates TLS during the handshake and reverse-proxies clean requests to your origin. The two planes talk to each other through a single authorization lookup, and keeping them separate is what makes the whole thing fast and safe.
The reason onboarding feels hard is that the connect plane traditionally lands on the customer's desk. Your platform knows exactly which records it needs. The customer's DNS provider controls the zone where those records have to live. And the customer, who controls neither the record requirements nor the internals of their provider, gets asked to translate between the two by hand.
That gap is where the drop-off happens. A one-click connection closes it by detecting the provider, writing the records with the customer's consent, and verifying ownership for them, so nobody has to translate anything.
What the flow actually does
Here is the sequence a working connection runs through. The customer sees a single screen; the rest happens behind it.
- Detect the provider. We look up where the domain's DNS is hosted so we can speak to the right system instead of leaving the customer to find their zone editor.
- Get one consent. The customer approves a single plain-language screen. No values to type, no fields to match.
- Write the records. The exact records your service needs are applied by template, in the right fields, with the right targets, every time.
- Verify ownership. A value-checked challenge or a signed provider consent proves the customer controls the name before anything is trusted.
- Issue HTTPS. A certificate is requested, issued, and later renewed automatically. There is never a cert for anyone to wrangle.
The records themselves are not exotic. A typical connection needs an address record for the apex, a matching record for the www host, and a short-lived validation record so the certificate authority can confirm control. When the platform writes them, they look like this:
| Type | Name | Value |
|---|---|---|
| A | @ | edge.customdomain.ai (points the apex at the edge) |
| CNAME | www | edge.customdomain.ai (points the www host at the edge) |
| TXT | _acme-challenge | validation token (short lived, used once) |
The difference is not the records. It is who fills them in. When a person copies these by hand, they miss a trailing dot, drop a value in the wrong field, or forget one row entirely, and then the certificate never issues. When a template applies them, none of that can happen. You can see how a one-click connection writes these records without the customer ever touching a value.
Why on-demand TLS at the edge
Once DNS points at the edge, traffic for the new hostname starts arriving. Rather than pre-provisioning a certificate and hoping the timing lines up, the edge terminates TLS on demand during the handshake. The first request for an authorized hostname triggers issuance; every request after that is served from the cached certificate. Renewals happen the same way, quietly, with no ticket and no expiry surprise.
The lookup that keeps this cheap
The edge only terminates TLS for hostnames the connect plane has authorized, and it checks that with a single constant-time authorization lookup. That check stays out of your billing path and your business logic, so adding a domain never touches your application code.
That is the whole shape of it. The connect plane proves identity and writes configuration once. The edge plane answers traffic and manages certificates forever after. The customer approves one screen and moves on, which is the only part that ever mattered to them. Everything the old setup guide used to ask a person to do by hand is now something the platform does for them, correctly, in about the time it takes to read a sentence. If you want to give your customers that one-click connection, the two planes do the rest. Custom-domain onboarding does not have to be a support queue, and once these pieces do their jobs it stops being one.
Custom domains, on autopilot
Let your customers connect their own domain in one click. We detect their DNS provider, write the records, verify ownership, and issue HTTPS, while they just approve one screen.
Get started