One domain, connected
For years I used Firebase's custom-domain feature and never once knew how it worked. You typed your domain, you copied a record into your DNS, you waited, and eventually a green check appeared and your site was live over HTTPS on your own name. It felt like magic.
Giant Context hosts every customer's site, and a hosted site nobody can reach on their own domain is a demo, not a product. A customer connecting a domain, start to finish, runs through four systems, and one piece of it still makes me nervous.
What the customer wants
A customer owns coffeeroasters.com, bought years ago from some registrar. They built a site in my console. They want the two facts to become one fact. Type the domain into settings, and have their site answer at coffeeroasters.com over HTTPS, with the padlock every real website has.
Everything between that wish and that padlock is four separate systems agreeing with each other, three of which I do not own. The customer's registrar. Google's certificate infrastructure. The public DNS system. And my platform just waits.
Station one, prove you own it
The first thing the platform does is refuse to trust the customer.
Anyone can type coffeeroasters.com into a form. Proving they control it is different, and the proof is a DNS record only the real owner could add. When the customer starts the process, my server asks Google's Certificate Manager to create a DNS authorization, and Google hands back a specific record to place, a name and a value that mean nothing to anyone but Google's verifier. The customer copies that record into their registrar's DNS settings, next to the record pointing the domain at my load balancer's IP address.
This is the standard I learned from being on the other side of it at Firebase for years. You never ask a user to prove ownership by email or a phone call. You ask them to change DNS, because changing DNS is something only the domain's actual controller can do. The proof is the same action as the setup.
Station two, the blind wait
The next part is the one I do not love.
DNS does not happen when you save it. The customer adds the record, and then it propagates. Sometimes seconds, sometimes hours. Google's verifier will notice the record exists, eventually, and until it does the domain sits in a state my database calls verifying_dns.
The whole lifecycle is these six words:
The six verification states
type DomainVerificationStatus = | "pending_dns" // waiting for the customer to add the record | "verifying_dns" // waiting for Google to see it | "provisioning_cert" // waiting for the certificate | "provisioning_map" // wiring the cert to the load balancer | "active" // live | "failed";Four of the six states are the word waiting. This feature is mostly a state machine for other machines' latency.
And Giant Context cannot see into any of it. It cannot promise four more minutes. It can only ask Google, right now, has the record shown up, and get back yes or not yet. So the console has a Verify Now button, and behind that button is a single call that nudges the state machine one step forward if it can. Click it, and either the domain advances or it stays put. No progress bar, because there is no progress to report, only a question you can ask again.
The rest of my platform is not like this. Everywhere else, I know exactly why something is slow and roughly when it will finish. This one corner runs on three external systems and a global cache layer, and the honest user experience is ask, and ask again. It is the part of the product I have the least faith in, not because it is wrong, but because I cannot make it feel certain.
Station three, the certificate provisions itself
Once Google confirms the record, the machine moves on its own the next time it is nudged. The DNS authorization becomes proof, and my server asks Certificate Manager for a Google-managed certificate for the domain. Managed is the important word. I never see a private key, never run a renewal cron, never get paged at 2 a.m. because a cert expired. Google issues it, renews it forever, and my code's entire involvement is asking for it and writing down its name.
For an apex domain, the bare coffeeroasters.com with no www, the platform asks for a wildcard certificate covering the domain and its subdomains together, because apex domains carry their own small set of networking rules, and one wildcard is cheaper than handling each subdomain on its own.
Station four, the certificate meets the load balancer
The last state before active is provisioning_map, and it is the one that taught me the most, because it is pure GCP networking, which I do not work in often.
I can spin up a hundred Cloud Run instances without thinking. But the network layer, the load balancer and the certificate map that sits in front of everything, is something I set up roughly once and then hope never to touch again. A load balancer can serve many certificates, and it decides which one to present by consulting a certificate map, a lookup from hostname to certificate. The final step of connecting a domain is adding one entry to that map, giantcontext-lb-******, so that when a browser arrives asking for coffeeroasters.com over HTTPS, the load balancer has a certificate with that exact name ready to present.
Entry added, state flips to active, and the domain is connected. The next stranger who types coffeeroasters.com gets the customer's site, fast and encrypted, and never knows any of this happened.
Why it is built this way
The shape of this makes sense. Every hard part of this feature is a thing I chose not to own. I do not verify domains myself, I ask Google's authorization to. I do not issue or renew certificates, Google's managed certs do. I do not run the DNS, the customer's registrar and the internet do. Giant Context's actual code is a small state machine that asks three external systems polite questions in the right order and writes down the answers.
That is the correct division of labor, and it is also the source of the uncertainty. The systems I lean on are more reliable than anything I would build, and they are also opaque to me by design. It's trust issues... probably a me problem.
Wiring this up yourself
If you are serving customer domains from GCP, the pieces are these, and none of them are as scary as the first setup makes them feel.
Prove ownership with a DNS authorization from Certificate Manager. It gives you the record to hand the customer and the verification you can poll.
Let Google own the certificate. Managed certificates renew themselves, which removes the single most common way a custom-domain feature breaks in year two, the forgotten renewal.
Put a certificate map in front of your load balancer. One map, one entry per domain, hostname to cert. This is the part you set up once and should document heavily, because you will forget it, since you touch it so rarely.
And build the wait honestly. You will not be able to show a progress bar, because you are waiting on systems that do not report progress. A clear current state and a re-check button beats a fake progress bar that lies.
Building something like this
I'm Jesse. I build platforms end to end, and I'm open to work. If this is the kind of engineering you need, get in touch.