How to Set Up Custom Domains for Your Customers (The Right Way)

A key feature for any SaaS product is allowing customers to use their own custom domains. But behind the scenes, this simple-looking feature is a complex and often underestimated engineering challenge.

If you've ever tried to build a custom domain system, you know the process is a series of headaches: managing DNS records, provisioning SSL certificates, ensuring everything stays online & up-to-date, and even the volume of support tickets that come from a faulty system. In this article, we'll walk you through the manual process of setting up custom domains with tools like Let's Encrypt and then show you a better, more scalable way to handle it with an automated solution.

The Problem: The 1-to-N Domain Challenge

For a single customer, setting up a custom domain is manageable. You can manually configure a CNAME record and run a few commands to get an SSL certificate.

But what happens when you have 100, 1,000, or even 10,000 customers, each with their own custom domain? This is the 1-to-N Domain Problem.

This complexity leads to what we call "The Unseen Cost of Custom Domains", the hidden expense that comes from dedicating your engineering team to maintaining infrastructure instead of building your product. These hidden costs can be detrimental to a growing SaaS business

Your small engineering team suddenly finds itself swamped with:

• Manual DNS Configuration: Guiding non-technical users on how to set up CNAME records, a process that is often prone to human error and can lead to a high volume of support tickets.
• Certificate Lifecycle Management: Manually running ACME clients, securely storing private keys, and ensuring certificates are renewed every 90 days. A single failed renewal can lead to a broken website and lost revenue for your customers.
• Routing Infrastructure: Dynamically routing traffic for thousands of domains to the correct backend service. This requires a complex and custom-built load balancing system that is both scalable and reliable.
• The "What If" Scenarios: What if a certificate fails to renew? What if a user's DNS changes and breaks their domain? Handling these edge cases manually is a recipe for engineering burnout.

The Manual Process: A Deep Dive into the Code

Let's walk through what the manual process looks like for just one domain. For this example, we'll assume you have a backend server and are using Let's Encrypt with a tool like certbot.

Step 1: Manual DNS Validation

The first step is to validate that you control the domain. This is typically done with a DNS-01 or HTTP-01 challenge. For a small scale, you might run an ACME client manually.

#!/bin/bash

# A simple script to get a certificate 
DOMAIN="app.yourcustomer.com" 
CERTBOT_DNS_API_KEY="YOUR_DNS_API_KEY" 

# This command requires your DNS provider to have a certbot plugin 
certbot certonly --dns-cloudflare \ --dns-cloudflare-credentials " $CERTBOT_DNS_API_KEY" \ -d "$DOMAIN"

This script works for one domain, but you'd need a different script for each DNS provider your customers use. It's a logistical nightmare. In fact, relying on manual processes and fragile bash scripts to handle a core business function is the definition of a DevOps nightmare.

Step 2: The Routing Infrastructure

Once the certificate is issued, you need a way to route traffic. A load balancer like HAProxy or Nginx is a common choice.

# /etc/nginx/sites-enabled/app.yourcustomer.com 

server { 
    listen 443 ssl; 
    server_name app.yourcustomer.com; 
    ssl_certificate /etc/letsencrypt/live/app.yourcustomer.com/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/app.yourcustomer.com/privkey.pem; 
    location / { 
        proxy_pass http://your-backend-server; 
        # ... other proxy configurations ... 
    }
}

This is a static configuration. To scale this, you'd need a cron job or a separate script to check for new domains, generate this file, and gracefully reload Nginx without interrupting service.

Step 3: Certificate Renewal

Let's Encrypt certificates are only valid for 90 days. So, you must automate the renewal process. A common approach is a cron job.

0 0 1 */3 * /usr/bin/certbot renew --quiet

This script will run every three months. But what if a domain is no longer in use? What if the DNS records have changed? Without a robust system, this is a recipe for broken certificates and support tickets. In a multi-tenant SaaS environment, this becomes a ticking time bomb of expiring SSL certificates that can lead to unexpected downtime and a loss of trust. Furthermore, the ACME protocol itself has strict rate limits, which can halt your ability to issue new certificates if your automation fails and tries to renew a certificate too many times.

The Scalable Solution: How an Automated Platform Solves This

This is where a platform designed specifically for this problem shines. Instead of building and maintaining this complex infrastructure yourself, you can use a single, unified solution like VanityCert.

1. Your Customers Handle DNS: You provide a secure, branded portal where your customer adds their custom domain. We give them a single CNAME record to add to their DNS. That's it.
2. VanityCert Handles Everything Else: Once the DNS record is configured, our platform takes over. We automatically:
   • Validate the DNS: We constantly check for the correct DNS record.
   • Issue a Certificate: We provision and install a free SSL certificate for the domain.
   • Route Traffic: We dynamically route traffic to your backend servers.
   • Automate Renewals: We handle all 90-day renewals, ensuring certificates never expire.

A Look at How It Works in Your App

Instead of writing complex bash scripts, your application would simply make a single API call to VanityCert.com.

curl --location --request GET 'https://app.vanitycert.com/api/domains/' \
--header 'X-API-KEY: bb40596f49a05dfa2730bc88f0558f742b707073888abfa80f77e811ccb71115' \
--header 'X-API-KEY-ID: vc_pk_NxDcbzsZSY28kbjjCvFiNU' \
--header 'Content-Type: application/json' \
--data '{
    "serverId": 1,
    "url": "http://test.com"
}'

This one API call is all you need. VanityCert does the rest.

Built for Reliability, Scalability, and Security

By outsourcing this core infrastructure to a dedicated platform, you get a system that is:

• Scalable to 10,000+ Domains: Designed from the ground up to handle a massive number of domains.
• Reliable: We have built-in retry and failure handling to ensure certificates are always valid.
• Secure: We handle all certificate provisioning and private key management in a secure, encrypted environment.

Ready to Ditch the DevOps Nightmare?

Building a custom domain system from scratch is a significant technical undertaking. While it's possible to do it manually with scripts, the long-term maintenance and scaling challenges can quickly overwhelm your engineering team.

By offloading this infrastructure to a purpose-built platform, you free up your team to focus on what matters most: building an amazing product for your customers.

If you’re tired of managing this complexity and want a simpler, more scalable solution, get in touch with our team to explore how VanityCert can help your business grow.