The ultimate guide to custom domains for your SaaS app

As your SaaS business grows, customers will inevitably inquire about custom domain integration. Custom domains not only enhance branding and security but also simplify navigation and white-labelling for your clients. In this guide, we'll cover everything you need to know about implementing custom domains for your SaaS application.

Interested in a straightforward solution for custom domain implementation in your SaaS? Try saascustomdomains.com for a seamless experience.

Why Custom Domains Matter

The use of a custom domain allows your customers to mask the fact that they are using a SaaS product and makes it seem like the product is a part of their organization. It also allows you to brand the product as your own and add an extra layer of security.

If you are sending emails with links on behalf of your customers, for deliverability reasons, customers may want all the links in these emails to be on their own domain.

If you are running a website builder or eCommerce platform you want to let people have their websites and shops on their own domains.

Some SaaS products offer white-label versions of their product. This means that customers can re-brand the product and use it and sell it as their own. This would not be possible without custom domains.

Custom domains are easy to remember. Even though Redis uses Better Stack for their status page, I can visit status.redis.com and see their status rather than remembering a complicated URL like app.betterstack.com/status-page/redis-cloud-ac23 or similar.

So, now that we know some of the many reasons why customers want to use custom domains, let’s dig in.

In this article, we'll cover all you need to know to set up custom domains for your SaaS app.

The almighty DNS

First things first, how does the customer’s domain even send someone to your application? It's simple; they need to create a DNS record or two and direct their domain to your app.

Should I use the CNAME or A record?

If your customer wants to have your app on a subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your app.

If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your app’s IP address.

If using the A record, ensure your server IP is static and doesn't change, ever! In case it changes you’ll have a bad time. All the existing A records your customers created will then point to the old IP that doesn’t belong to your app server. Get ready for a sleepless night.

Note: some DNS management systems, e.g. Cloudflare, allow you to have a CNAME record on the apex domain. To enable this they use the technique called CNAME flattening. What it actually means is that Cloudflare will check to what IPs the CNAME value is pointing at and create A records with those IPs on your apex domain for you.

Great! Now we know how to point traffic from the customer’s domain to our own app, and if we should use CNAME or A records. Easy-peasy, yeah? Not so fast, Hackerman.

If your customers just point their domains to your app and try to visit the domain, they’re in for a nasty surprise.

Your app doesn’t support HTTPS for these custom domains yet. Without HTTPS the browser will show an ugly warning and prevent the user from accessing your app.

How to make HTTPS work?

To enable HTTPS, set up a reverse proxy that handles TLS termination before your application server.

You can run the reverse proxy on a separate machine or on the same machine where your application server is running.

Do you remember the CNAME and A records from above? Your customers will actually point their domains to your proxy. The proxy will handle TLS and then forward requests to your application server In order for the reverse proxy to handle HTTPS, it needs to have access to the TLS certificates for the domains it’s serving. We can ask customers to generate the certificates themselves and send them to us, but there is a better solution. Once your customer has pointed a domain to your proxy, they gave you control of the domain. This lets you generate the TLS certificate for the domain.

To obtain certificates, use a Certificate Authority (CA) like Let’s Encrypt or ZeroSSL. The good people behind these services allow us to generate TLS certificates for free! I’ll quote the Let’s Encrypt documentation, but the same thing applies to ZeroSSL.

Let’s Encrypt uses the ACME protocol to verify that you control a given domain name and to issue you a certificate. To get a Let’s Encrypt certificate, you’ll need to choose a piece of ACME client software to use.

There are many 3rd-party ACME clients for Let’s Encrypt. The official recommendation is to use Certbot. These clients will take care of issuing and renewing certificates automatically.

Find the one that suits you best and use it. With some clients, you can combine the certificate issuing with TLS termination and reverse proxying, e.g. Apache, Caddy, Nginx, etc.

How to handle it on my backend

Your reverse proxy is now hopefully issuing certificates, renewing them automatically, terminating TLS, and proxying requests to your backend.

But, we’re not done yet. Our application still needs to handle the request, and for that it needs to know the original domain from which the request is originating. The way we solve this is by making the proxy append the header, e.g. X-Served-For, with value of the original request’s Host.

Your application can read the value of this header and see the domain from which the request is coming from.

Based on the domain, you can handle the request differently, only serve certain data, only let certain users log in etc.

Keep in mind that if you have multiple proxies in front of your backend, e.g. a CDN or a load balancer, make sure that they don't strip out this header, or your application won't work as expected.

Extras

To achieve high availability and reliability, and to handle more traffic, use a fleet of reverse proxies behind a load balancer. Use services like AWS ECS or EBS for automated recovery in case your proxy fails, otherwise, you may be waking up in the middle of the night restarting proxies manually.

If you want us to handle all of this complexity for you, check out saascustomdomains.com. Your SaaS could be running on custom domains in less than 10 minutes.

Summary

In this post, we learned about all the different parts necessary to implement custom domains feature for an application. We did a high-level overview of DNS, CNAME vs A records, generating and renewing certificates, reverse proxying requests to your application, and handling the requests for different domains.

In the next posts, I'll dig into parts of this system in more detail. I will cover how to exactly do the reverse proxying, how to issue and renew certificates, how to config etc.

I'll also dig into different services that can be used to implement custom domains like Heroku, Render, Cloudflare, etc. and the pros and cons of each service.

I'll show even more approaches to solving this problem, some of which are very interesting and weren't possible to implement until recently thanks to the new DNS standards and providers.

If you want to simplify custom domain integration for your SaaS customers, try saascustomdomains.com today.

Stay tuned, and until next time!

Do you have any questions?

Contact me via Twitter at @dragocrnjac, via email at drago@saascustomdomains.com, or at saascustomdomains.com via the chat widget.

If you're looking for a done-for-you custom domains solution to save time and money, check out saascustomdomains.com. We offer a bunch of options from providing the custom domains service to deploying the custom domains service in your own cloud — AWS, Google Cloud, Azure etc.