A Home for Every Subdomain
How a growing homelab system got its own domain, a subdomain strategy, and a Cloudflare Tunnel to tie it all together.
Part 11 of the series: Building The Hub
Naming things is supposed to be one of the two hard problems in computer science. But it gets worse when the things you need to name keep multiplying.
By early March, The Hub had grown from an Obsidian vault and a GitHub repo into a sprawling system: three AI agents on a homelab container, an automation platform on another, a chat app, a capture app, an MCP gateway, and a blog. Each needed to be reachable. Each had a URL. And those URLs were a mess.
The domain sprawl problem
Here is what happens when you build things incrementally without a naming plan. You register a domain for your email years ago. You pick a different domain when you deploy your first Firebase app. A third domain shows up when you need something for a side project. Before you know it, you have services scattered across three registrars and two DNS providers, with no coherent naming scheme connecting any of it.
My chat app lived on one domain. The capture app lived on a subdomain of the same domain. The MCP gateway was accessible through a completely different domain. The automation dashboard had no public URL at all — just a local IP and port that only worked when I was on my home network.
It was functional, technically. But it was also impossible to remember, hard to explain, and gave the whole system a “duct tape and hopes” energy that did not match the engineering going into it.
Level 7 clearance
The Hub already had a S.H.I.E.L.D.-inspired naming convention. Nightcrawler, Gideon, JARVIS, SAGE, Cybertron — every component had a codename from the Marvel/DC universe. The domain needed to fit that theme.
In the S.H.I.E.L.D. hierarchy, Level 7 is where things get interesting. It is the clearance level where you learn about the Avengers Initiative, where Coulson operates after his “death.” It felt right for a personal infrastructure system — not the public-facing stuff, but the layer underneath where the real work happens.
The TLD choice was straightforward — developer-focused, HTTPS-enforced by default, and priced at-cost through Cloudflare Registrar. One registration later, I had a domain that fit the theme and the purpose.
The subdomain strategy
With a single domain locked in, I could finally think about naming systematically. The rule was simple: subdomains describe function, not technology.
Not firebase-app-1 and firebase-app-2. Not container-3-service or vm-b-api. Just what the thing does:
chat— the Hub Chat interfacecapture— the mobile capture PWAmcp— the MCP gateway for agent toolsn8n— the automation dashboardblog— this blogstatus— uptime monitoring
Each subdomain is a front door. What is behind that door — Firebase Hosting, a Cloudflare Tunnel to a homelab container, a static site — is an implementation detail the URL does not need to leak.
Two routing layers
The subdomains split into two categories based on how they are routed.
Firebase Hosting handles the web apps. The chat interface and capture PWA are both deployed to Firebase with custom domains. Migrating them from their old subdomains was straightforward — add the new custom domain in the Firebase console, update DNS records, wait for SSL provisioning, remove the old domain. The only wrinkle was that Firebase needs you to verify domain ownership with a TXT record before it will provision the SSL cert, and if you are moving from a different registrar, you need to add that TXT record at the new DNS provider first.
Cloudflare Tunnel handles the infrastructure services. The MCP gateway and automation dashboard both run on homelab containers with no public IP. A Cloudflare Tunnel creates an encrypted outbound connection from the container to Cloudflare’s edge, and Cloudflare routes incoming requests to the right container based on the subdomain.
This means I never need to open ports on my router or deal with dynamic DNS. The tunnel handles everything, and Cloudflare’s edge provides DDoS protection and SSL termination for free.
Zero Trust for sensitive endpoints
Not every subdomain should be publicly accessible. The automation dashboard, for example, has full control over workflows that can read my email, manage my task lists, and interact with external APIs. Putting that behind a public URL without authentication would be reckless.
Cloudflare Zero Trust Access solved this cleanly. I added an access policy that requires email OTP authentication for the automation subdomain. When I navigate to it, Cloudflare intercepts the request, sends a one-time code to my email, and only grants access after verification. No VPN required, no client software to install, works from any device.
For the MCP gateway, the access pattern is different — agents need to reach it programmatically, so it uses token-based authentication instead of interactive login. Different subdomains, different security models, same domain.
The domain landscape
The final picture has three domains, each with a clear purpose:
- A professional domain for career-related things — portfolio, professional email, LinkedIn references
- A legacy domain for personal email that has been running for years and is not worth migrating
- The new domain as The Hub’s central home — all infrastructure, all apps, all agent-facing services
Three domains is manageable. The key difference from before is that the new domain has a plan. Every new service gets a subdomain. The naming is predictable. If I build a new tool tomorrow, I already know what its URL will look like.
It is just naming
This is a short post because the work itself was not complicated. DNS records, Firebase console clicks, a Cloudflare Tunnel config, and an access policy. A Saturday afternoon, maybe.
But getting the naming right changed how the whole system feels. URLs that make sense, that I can remember, that I can tell someone verbally without spelling out four random words. The Hub went from a collection of services to something that looks like it was designed on purpose.
Sometimes the most impactful infrastructure work is not about the infrastructure at all. It is about giving things the right names.