CUSTOM DOMAIN
Build it if your team can spend months on multi-tenant TLS and keep staffing DNS tickets after ship. Buy it if you'd rather ship in days and let a managed layer absorb the provider differences, the certificate renewals, and the support tickets that come from a customer's registrar changing a record without warning. One production postmortem from a team that built this in-house put real numbers on the "staff it forever" side: over 200,000 live domains, and a system that runs more than a billion background jobs just to keep certificates current (Elixir Forum, founder postmortem, 2023-06-24).
That's the real shape of the decision. Below: what building actually costs, a fair look at the tools already solving this, and where Custom Domain fits if you'd rather not build it a fifth time.
What does it actually cost to build custom domains for SaaS yourself?
On paper, adding a custom domain is one CNAME record. In a multi-tenant product, it's a systems project with no natural end date.
Multi-tenant TLS. Every customer domain needs its own certificate, issued and renewed without downtime, without ever serving a certificate for a hostname you haven't verified. Get the verification step wrong and you're one misconfigured wildcard away from serving the wrong customer's content on the wrong domain.
DNS across dozens of providers. Customers' domains sit at GoDaddy, Cloudflare, Route 53, Namecheap, Google Domains, and dozens more, each with its own record quirks, propagation timing, and support UI. The Domain Connect protocol covers a meaningful slice of registrars with a standard template flow — worth implementing before anything custom. It doesn't cover all of them, so the build still needs direct API integrations, or manual instructions, for everything Domain Connect doesn't reach.
Certificate renewal and drift detection. A domain that verified cleanly on day one can silently break on day 40 when a customer repoints their CNAME, deletes a TXT record, or migrates registrars. Without ongoing checks, the failure shows up as a support ticket, not an alert — usually the exact failure modes a support team ends up naming by hand: wrong MX priority, a missing trailing dot, a split TXT record that got truncated by a registrar's UI.
Teams that build this well end up publishing what it took: framework-specific walkthroughs like Authress's eight-step AWS CloudFront and ACM guide for adding a custom domain (dev.to, published 2022-02-25, updated 2024-10-08) are still being revised two years after publication — a decent proxy for how long this stays a maintenance job, not a one-time build. Fly.io shipped its own custom-hostname SSL provisioning API and launched it on Hacker News to a strong reception (90 points, 47 comments, Show HN) — evidence the problem is real and solvable, and also evidence that solving it well is worth a launch post of its own.
None of this is a documentation problem. It's an architecture problem: two systems, your product and the customer's DNS provider, are talking through the customer instead of to each other. Better docs make that translation step less confusing. They don't remove it.
What's the landscape of ways to add custom domains to a SaaS product?
A fair map of what's already out there, by approach:
Cloudflare for SaaS. An enterprise-grade custom-hostname platform, documented in depth at developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/domain-support. It's a strong option if your traffic already routes through Cloudflare's edge — the tradeoff is that custom-hostname management is tied to that edge, so adopting it means adopting Cloudflare as your request path, not just your certificate issuer.
Vercel (multi-tenant / Platforms). Vercel bundled custom-domain APIs into its hosting platform with the "Vercel for Platforms" launch (vercel.com/changelog, 2025-12-05), backed by a forkable reference app that's become the category's most-adopted starting point: github.com/vercel/platforms, at 6,694 stars and 1,054 forks as of July 2026. It's a well-built answer for teams already hosting on Vercel — like Cloudflare's approach, the domain layer is tied to the platform underneath it.
Point solutions. A smaller set of vendors solve custom domains as a standalone problem, closer to what most multi-tenant SaaS teams actually need: Entri pairs a DNS-configuration widget with a domain-sales API and heavy docs at developers.entri.com; Approximated runs custom domains as a reverse-proxy-as-a-service, with framework-specific guides for Laravel, Next.js, and Rails at approximated.app/guides; SaaS Custom Domains offers a managed, white-label custom-domain API with a single long-form pillar guide at saascustomdomains.com. Each is a real, working answer to the same problem — the differences show up in provider coverage, certificate handling, and whether the tool was built for a human clicking a dashboard or a platform calling an API.
DIY. Covered above. Real, shippable, and the maintenance bill doesn't stop after launch.
Where does Custom Domain fit in this landscape?
A custom domain connection layer detects a customer's DNS provider, writes the required records, verifies ownership, and issues HTTPS — without the customer or your support team ever opening a DNS panel. That's the category Custom Domain builds for, and the design choices follow from it:
- One call starts a connection.
POST /v1/connectionsinitiates detection, record writes, verification, and certificate issuance as one flow. A typical connection goes live in about 30 seconds. - Provider-agnostic, not edge-tied or platform-tied. Custom Domain auto-configures 25+ DNS providers. Where a provider supports Domain Connect, the connection uses that protocol directly — Custom Domain extends Domain Connect's reach rather than replacing it. Where a provider doesn't support it, direct API integrations fill the gap, so coverage doesn't stop at the protocol's own limits.
- Consent-gated, not credential-based. Connections use an OAuth-style model for DNS access. Registrar passwords are never seen or stored.
- Fail closed. No unapproved hostname is ever served a certificate — the same discipline the "multi-tenant TLS" cost above is describing, handled once instead of per customer.
- Drift doesn't wait for a support ticket. Hourly checks catch a repointed CNAME or deleted TXT record and fire a webhook before a customer notices anything broke.
- Idempotent by default. Retries never double-count a connection — a small detail that matters a lot at the volumes multi-tenant platforms actually run.
- MCP server included. AI agent platforms provisioning domains programmatically get the same verification gates a human gets through the dashboard.
The architecture is a two-plane design where the control plane is never in the request path — the part that decides whether a connection is valid stays out of the way of the part serving live traffic. Custom Domain runs SOC 2 and ISO 27001 (2022) certified, and GDPR compliant.
Who should build, and who should buy?
If you're shipping your first custom domain for a handful of customers, the build-vs-buy math is close — a single integration, done once, is a reasonable weekend project. The math changes fast for multi-tenant SaaS platforms, site builders and PaaS products, agencies managing a book of client domains, and AI agent platforms creating sites programmatically — anyone whose "one customer" becomes hundreds or thousands of domains, each with its own provider, its own renewal clock, and its own way of breaking.
Getting your first domain live is the easy part to self-serve. The harder conversation — multi-tenant SSL at scale, automating domain setup across a growing customer base, migrating off hand-rolled CNAME instructions in your docs — is the one worth having directly.
Connecting more than a handful of domains? Talk to us. Or start self-serve: connect your first domain and see the flow before you commit to anything.
Frequently asked questions
What is a custom domain connection layer?
A custom domain connection layer is a managed system that detects a customer's DNS provider, writes the required records, verifies domain ownership, and issues HTTPS — without the customer or your support team touching a DNS panel. It replaces a manual, per-customer DNS process with a single automated flow.
How long does connecting a custom domain actually take?
With a managed connection layer, a typical domain goes live in about 30 seconds once the customer's DNS provider is detected. Hand-rolled setups vary widely — the time is usually spent in support back-and-forth over which record to add, not in DNS propagation itself.
Do our customers need to touch DNS records themselves?
No, if the connection layer is built to remove that step rather than document it better. The product should detect the provider and either write the records automatically or walk the customer through a single consent step — not hand them a CNAME value and a support article.
What happens if a customer's DNS provider isn't directly supported?
Coverage gaps are where most in-house builds and narrower point solutions struggle. A connection layer built to extend Domain Connect and add direct API integrations on top of it should be able to add new providers without a full rebuild — worth asking any vendor how many providers they cover today and how a gap gets closed.
How is this different from Cloudflare for SaaS or Vercel's domain APIs?
Cloudflare for SaaS and Vercel both solve custom domains well for teams already committed to their edge or hosting platform. A provider-agnostic connection layer solves the same problem without requiring a change to where your product already runs — it's a layer you add, not a platform you migrate to.