If your building a web product, you must have thought once about providing domain of customers choice. This already is a popular and widely used method for SAAS products. While someone in the industry would already know about this, but for beginners and just application developers, it might be a mystery as it was for me a few year ago. But if you know the right concepts its actually not that complex. And today we are exactly going to debunk that.

At twimbit we wanted to give our partners the flexibility to host there content on domains of there choice. twimbit, an ecosystem for research analyst to discover and shape research provide creators of research the needed tools.

The inspiration came from hashnode and medium where they were already providing this feature to there customers for years. There are many merits to it as compare to providing just a handle/ path based service ( handle.twitter.com vs twitter/handle) –

1. Easy to remember for visitors
2. Better brand visibility and marketing
3. SEO bifurcation – Google doesn’t index the subdomain at the same level of primary domain so customer can enjoy there standalone SEO benefits.
4. Prevents third party cookie sharing. ( Plus on privacy but minus on authentication)

What Custom domain options are there –

1 Sub Domain Level –

<custom>.domain.com

In this type configuration, you provide the customization on the subdomain while the primary domain remains the same. Its easy to implement and is widely popular. e.g. company.slack.com

I personally prefer this option as it is easier to maintain and scale. As holder of primary domain we can do upgrades, change configurations and propagations are really handy. Plus Authentication is much easier then our second option.

2 Primary Domain Level

customdomain.com

Well as the name suggests, this is directly offering customer the domain of there choice to point at your service. While providing this kind of functionality we assume that customer purchases there own domain and just needs it to point to our servers.

This where the problems starts. First of all if you want to put analytics or do cookie based authentication, that wont simply work out of the box as browsers now prevent 3rd party cookies. The reason for that is as now the cookie exist on this specific domain hence your primary service wont have control over it anymore. Most of the analytics services also uses the same method to track and bind user identities. Other challenges include DDOS handling, domain registration and propagation.

Before Getting into the solution Before Getting into the solution straight, lets list down the challenges associated, that you have solve first. Now finally able to solve it depends upon solving each of them individually first so clearly you need to know things from man different disciplines of web development. This is what makes this even more difficult as I couldn’t find one place where the solution was presented collectively.

Challenges

These challenges are in the order of request travel –

1. DNS Handling for subdomain and primary domains
2. Creating Global CDN service for minimum latency
3. SSL certificate / TLS on Demand with Caddy
4. Reverse Proxy with Caddy
5. Request Caching with Varnish
6. Application Request Handling for custom domains
7. Authentication for custom domains

Schematics of the solution Prerequisites to solve this challenges.

1. Knowledge about DNS – A record, CNAME
2. Server setup – Ubuntu, SSH, Docker
3. Application Development – Node.JS / PHP

In this series of blog we will cover all of them one by one so that you go back with all the knowledge you need to setup an equivalent service.

Recommendation

I won’t recommend this solution to developer and startups who are just starting there application development as this is not a must have but a good to have functionality. Once you have this kind of setup you are inviting whole set of problems which might distract you from your core. To be honest, for us this was somewhat equivalent to creating our own CDN and we did. We did it so our customers don’t need to go through the same pain.

But if you still desire to get this flying arrow, you would want to take a out of the box route as well –

1. AppFleet ( To be shut Downed )
2. FLY.io
3. Cloudflare Enterprise Plans

We didn’t used them because after analyses, the cost of build vs buy was equivalent. The AppFleet shutdown happened while I was just starting to do this research and thank God that the timing was right. You always need to consider the possibility of out scaling your provider or they going bankrupt/ shutting down. You cant hope to change or migrate from this setup after you get started. So you have to play your cards right the first time.

I would be very glad to have discussion with you and answer any of your questions. You must clear any doubts you have before beginning this long and tiring journey. It took us almost 6 months to solve this problem and there are few things that still haven’t been solved like automatic custom domain authentication and Autoscaling in Global locations.

Is it worth the pain ?

Simple answer would be that it depends upon the level of torture you can take. As said earlier there are 7 steps to solving this challenge and multiple things can go wrong at each step. So you need to really have perfection up to last edge. You can’t hope to fix these things on the fly as any issue means downtime for you customers. Unfortunately we had this too but our customer were kind enough to give space to play and tolerated our mistakes. I would recommend to perfect each stage independently, have an isolated testing methodology for each step and then start integrating different stages from bottom to top.

IF you get everything right the, solution works like magic – congratulation you have master different disciplines and survived through integration hell. Your customer may not know this problem because on individual level they have done this several time with there own website. But there is a big IF. Creating a service that handle fleet of custom domains with all microservices and global coverage is a something undiscussed as it is taken care by big players like Cloudflare, GitHub, medium etc.

If your bread and better is preventability for your customers then sure do this otherwise focus on your core and provide this as a feature later when you go mature.

So in upcoming blogs I will debunk each challenge and provide all the knowledge you need.