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
One of the first hurdles in custom domain integration is understanding the backbone of the internet – DNS. Without it, navigating this landscape is like sailing without a compass.
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.
While the steps we've discussed are straightforward, executing them at scale demands a unique expertise. This is where saascustomdomains.com shines. Let us navigate the intricacies for you, and have your SaaS running on custom domains in under 10 minutes.
Summary
Today, we demystified the essentials of implementing custom domains for your SaaS application. From a deep dive into DNS specifics like CNAME vs A records to the nuances of certificate management and request handling, we've covered the groundwork. But the journey doesn't stop here!
What's Next?
Stay tuned as we delve further:
Check out our Beginner's Guide to Reverse Proxying
Read why saascustomdomains.com is a Smarter and More Affordable Alternative to Cloudflare
Or jump straight into implementing custom domains in your app with our guides for the most popular web frameworks:
Connect & Simplify
Questions or feedback? Reach out on Twitter @dragocrnjac, via email, or chat with us directly on saascustomdomains.com.
For a streamlined solution that saves you time and resources, consider saascustomdomains.com. We're more than a service; we're your partner in seamlessly deploying custom domains, whether on AWS, Google Cloud, Azure, or beyond.
Stay tuned, and until next time!
