#Method
#Testing
#Access Control
A platform this size, run by one person, keeps working through three test suites that never overlap. Unit checks the logic, integration checks the who...
Jesse James Richard
Read previous|
Feb 22, 2026Connecting a custom domain
|
6 min read
#Method
#Architecture
For years I used Firebase's custom-domain feature without knowing how it worked. Type the domain, copy a record into DNS, wait, and the site is live over HTTPS on its own name.
Giant Context hosts every customer's site, so I had to build that. It runs through four systems and I own one of them.
What the customer wants
This site is the case. jessejamesrichard.com is registered somewhere else, built in the console, and hosted on Giant Context, and you are reading it over HTTPS on its own name.
Four systems had to agree for that. The registrar holding the DNS zone, the public DNS system that propagates it, Google's Certificate Manager, and the platform, which waits on all three.
Proving ownership
Typing a domain into a form asserts nothing. Ownership is proved by writing a record into the domain's DNS zone, which requires access to the zone.
When a customer starts, my server asks Certificate Manager to create a DNS authorization for that domain. Google returns a TXT record, a name and a value, and the customer adds it at their registrar alongside the A record pointing the domain at my load balancer IP. Google's verifier reads the zone and confirms the value matches what it issued.
Email confirmation and phone verification prove access to an inbox or a number. Neither proves control of a DNS zone, and the zone is what has to change anyway for the domain to resolve here.
The blind wait
DNS does not take effect when the customer saves it. The record propagates, sometimes in seconds and sometimes over hours, and Google's verifier notices it whenever it notices. Until then the domain sits in a state my database calls verifying_dns.
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.
The platform has no visibility into any of it. It cannot report how far propagation has got or when Google will next check. It can ask whether the authorization has resolved and get back yes or not yet.
So the console has a Verify Now button, and behind it is one call that advances the state machine if the external condition is met. No progress bar, because there is no progress value to read.
Everywhere else in the platform I can say why something is slow and roughly how long it has left. Here the answer depends on a registrar's propagation, a global cache layer, and Google's verification schedule, none of which expose a position. The interface has to be a current state and a re-check, and that is the least certain thing I ship.
The certificate
Once the authorization resolves, the next nudge advances the state. My server asks Certificate Manager for a Google-managed certificate covering the domain, using the authorization as proof.
Managed means the private key never reaches my infrastructure, there is no renewal job to run, and expiry is not an operational event. Google issues and rotates it; my code stores its resource name.
For an apex domain, jessejamesrichard.com with no subdomain, the platform requests a wildcard certificate covering the apex and its subdomains together. Apex records cannot be CNAMEs, which constrains how the domain can point at a load balancer, and one wildcard avoids provisioning a separate certificate each time a subdomain is added later.
The certificate map
The last state before active is provisioning_map, which is the part of Google Cloud I work in least.
A load balancer can serve many certificates, and it selects one per request by matching the TLS server name against a certificate map, a lookup from hostname to certificate. Connecting a domain ends with one entry added to that map, so a client presenting jessejamesrichard.com in its handshake gets a certificate issued for that name.
Entry added, state flips to active, and requests for the domain resolve to the site over TLS. That is the request you made to read this.
Why it is built this way
Every hard part of this feature is something I chose not to own. Domains are verified by Google's authorization rather than by me. Certificates are issued and renewed by Google's managed service. DNS belongs to the customer's registrar and the internet. What Giant Context contributes is a small state machine that asks three external systems the right questions in the right order and writes down the answers.
The systems I lean on are more reliable than anything I would build and they are opaque to me by design.
Wiring this up yourself
If you are serving customer domains from Google Cloud, four pieces do it.
Prove ownership with a DNS authorization. Certificate Manager 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 most common way a custom-domain feature breaks in year two, the forgotten renewal.
Put a certificate map in front of the load balancer. One map, one entry per domain, hostname to certificate. Document it heavily, because you set it up once and then touch it rarely enough to forget how.
Build the wait honestly.
Hiring an early engineer, or building something like this
Remote, Pacific time, full-time or contract. Get in touch.