CustomDomainRouting

---

title: Custom Domain Routing for SaaS type: technique created: 2026-05-21 last_updated: 2026-05-21 related: ["radar/techniques/AWSSaaSLens", "radar/techniques/RESTAPIDesign"] sources: ["https://dev.to/carterbryden/how-to-allow-end-user-custom-domains-in-your-app-4hm0"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner

Custom Domain Routing for SaaS

A pattern for enabling SaaS customers to serve the application under their own domain (e.g., app.theircomain.com instead of theirtenant.yoursaas.com), using CNAME-based routing, wildcard TLS, and reverse proxy tenant resolution.

Why It's Needed

Multi-tenant SaaS products typically assign subdomains per tenant (tenant.saas.com). At the upper end of the market, enterprise customers require the application to appear under their own domain for branding, compliance, and SSO integration reasons. This is a recurring requirement for any product targeting business customers.

The Three-Component Pattern

1. CNAME delegation. The customer adds a CNAME record in their DNS pointing their domain to a platform-controlled endpoint:

app.customer.com  CNAME  routing.yoursaas.com

This hands control of the domain to the SaaS provider without requiring the customer to manage certificates.

2. Wildcard TLS via ACME. The platform needs a valid TLS certificate for the customer's domain. Two approaches:

• Wildcard certificate: works if all custom domains are subdomains of a shared root — not applicable for arbitrary customer domains.
• Per-domain certificate via Let's Encrypt ACME: the platform automatically provisions a certificate for each verified custom domain using the ACME HTTP-01 or DNS-01 challenge. Let's Encrypt issues free certificates; the challenge is automating issuance and renewal at scale.

Tools: cert-manager (Kubernetes), Caddy (automatic ACME), or custom ACME clients.

3. Reverse proxy tenant resolution. The proxy receives requests on the customer's domain and must identify which tenant to route to. Two resolution strategies:

• Domain-to-tenant lookup table: store a mapping of custom_domain → tenant_id in a database; the proxy queries on each request (cached with short TTL).
• SNI-based routing: TLS Server Name Indication carries the requested hostname; the proxy resolves the tenant before terminating TLS.

Verification Step

Before provisioning a certificate, the platform must verify the customer actually controls the domain. Standard verification: require the customer to add a TXT record with a platform-issued token before CNAME activation.

Operational Considerations

• Certificate renewal must be automated — Let's Encrypt certificates expire every 90 days.
• DNS propagation delays (up to 48 hours) affect the customer experience during onboarding.
• Rate limits on Let's Encrypt (50 certificates per registered domain per week) require planning for high-volume provisioning.

Radar Assessment

Custom Domain Routing for SaaS sits in the Assess ring of the Techniques quadrant, at inner position. First studied via the DEV Community article (2023-12-12). The pattern is well-established — Vercel, Netlify, and Render all implement it — but non-trivial to build: ACME automation, tenant resolution, and DNS verification each require careful implementation. Inner position reflects strong applicability to any SaaS product targeting the business/enterprise segment and a clear implementation path via existing tools (Caddy, cert-manager). Remaining gate is implementation on a product with at least one enterprise customer requiring a custom domain.