Glossary

Bring your own domain (BYOD)

Bring your own domain (BYOD) is a product capability that lets each of your customers run your SaaS on a domain they own, such as acme.com or app.acme.com, instead of on a shared subdomain of your platform. The customer keeps their brand in the address bar, and your product handles the DNS records, ownership verification, and HTTPS behind the scenes.

What does bring your own domain mean?

In a multi-tenant product, every customer normally lives at a subdomain you control, like acme.yourapp.com. Bring your own domain flips that. The customer points a domain they already own at your platform, and their end users see acme.com or app.acme.com in the browser. Your infrastructure still serves the pages, routes the traffic to the right tenant, and terminates TLS. The domain is the only thing that changes hands.

You will also see this called a custom domain, a vanity domain, or a white-label domain. They describe the same idea from slightly different angles: a customer-owned name replacing a platform-owned one.

Custom domain vs subdomain

A platform subdomain like acme.yourapp.com is simple to ship because you own the parent domain and can issue records and certificates for it instantly. The tradeoff is that your brand, not the customer's, sits in the URL. A custom domain like acme.com or app.acme.com puts the customer's brand front and center, but it lives at a DNS provider you do not control, so it needs cooperation from the customer's records and a verification step before you can serve it.

Most platforms offer both. New tenants start on a subdomain so they can go live in seconds, then upgrade to bring their own domain once they are ready to put their own name on the product.

Why do platforms offer bring your own domain?

Three reasons come up again and again. Branding: a customer's site or app looks like their own product, not a page rented from a vendor. Trust: visitors are more likely to sign in, pay, or share data on a domain that matches the company they expect. Deliverability and consistency: email, links, and cookies all sit under the customer's own name, which keeps their presence coherent across every channel.

For the platform, offering it is often a revenue and retention lever. Bringing a domain onto your product is a moment of real commitment, and customers who have done it are far less likely to leave. See how this plays out for site builders and website platforms.

What does it take to bring a domain onto a product?

Three things have to happen for a customer domain to serve traffic safely. First, DNS records: the customer adds a record at their DNS host that points the domain at your platform, usually a CNAME for a subdomain like app.acme.com or an A or ALIAS record for an apex domain like acme.com. Second, verification: you confirm the customer actually controls the domain, typically through a token in a DNS record, so no one can attach a name they do not own. Third, TLS: a valid HTTPS certificate has to be issued and renewed for that domain so browsers trust it. In a multi-tenant product this is multi-tenant TLS, often provisioned with on-demand TLS so certificates are created the moment a domain first resolves.

Done by hand, each step is a support ticket. The customer has to find their DNS panel, paste the right record type, wait for propagation, and hope the certificate lands. Every DNS host names its fields differently, which is where most of the confusion and back-and-forth comes from.

How Custom Domain handles bring your own domain end to end

Custom Domain runs the whole path so your customer never opens a DNS panel. It detects the customer's DNS provider, writes or hands back the exact records to add, verifies ownership, and issues HTTPS at the edge. Certificates renew automatically, and the domain starts serving traffic as soon as it resolves. Your team ships one integration, and the per-domain busywork disappears.

The result is that bring your own domain becomes a feature you can promise without staffing a support queue for it. For the full picture, read the complete guide to custom domains for SaaS.

Frequently asked questions

Is bring your own domain the same as a custom domain?

Yes. Bring your own domain, BYOD, and custom domain all describe letting a customer serve your product on a domain they own instead of a shared subdomain. The terms are used interchangeably.

Should new customers start on a subdomain or their own domain?

A subdomain lets a tenant go live instantly since you already control the parent domain and its certificate. Their own domain adds branding and trust but needs DNS and verification. Most platforms start tenants on a subdomain and let them bring their own domain when they are ready.

Can a customer use their root domain, like acme.com?

Yes. A subdomain such as app.acme.com uses a CNAME record, while a root or apex domain like acme.com needs an A or ALIAS record because DNS does not allow a CNAME at the apex. Custom Domain handles both and tells the customer exactly which record to add.

Do customers have to configure DNS themselves?

Not with Custom Domain. It detects the customer's DNS provider and writes the records or shows the exact values to paste, then verifies ownership and issues HTTPS automatically, so the customer never has to learn their DNS panel.

Who provides the HTTPS certificate for a customer domain?

Custom Domain issues and renews the certificate at the edge for every customer domain. Certificates are provisioned as domains come online and renewed automatically, so browsers always see a valid HTTPS connection without any work from you or the customer.