One domain, two systems that trust each other zero

My portfolio and my homelab live on the same domain and trust each other exactly zero. The site you’re reading this on is one system. The pile of machines in my closet is another. They share a single DNS zone and almost nothing else, and keeping that boundary honest is one of the quieter things I’ve built and one of the ones I’m most sure about.

It would be simpler to hand them separate domains, and I didn’t want to. One name, with a clean split underneath it: the public site at the apex, the homelab’s services on their own names. But sharing a zone means the boundary can no longer be “they’re far apart, it’s probably fine.” It has to be drawn on purpose, because the two systems are now close enough to touch, and “probably fine” is how close things end up wired together by accident.

Trust zero is easy to say and genuinely annoying to enforce, so here’s what it means in the walls. Separate deploy pipelines. No shared credentials between the two, none. Edge isolation, so the public site is served entirely out at the edge and a request for it never travels anywhere near the homelab. The homelab’s own public services don’t sit on an open port either. They’re reached through a tunnel that dials out from the box, so there’s simply nothing inbound to go knocking on. The site can’t reach into the homelab. The homelab doesn’t lean on the site. Wreck either one and the other doesn’t so much as flinch.

The part that taught me the most is the tokens, because that’s where “trust zero” runs into a platform that won’t always grant it. The rule is minimal scope: every deploy or automation credential gets the narrowest set of permissions that still lets it do its one job, so a leak is a small fire instead of the whole house going up. But the real work is finding where the platform won’t let you scope down. Some permissions can’t be narrowed to a single project. Grant a token the ability to edit one thing and it can quietly edit every thing of that kind on the account, because no project-level version of that permission exists. The platform hands you a key to the whole building and calls it a feature. There’s no clever config that fixes it. The permission simply isn’t that granular. So the only safe assumption is that a leak of that token reaches everything it could ever touch, and you design around that fact: store it like it’s radioactive, rotate it, and never let it sit somewhere a build log might cough it up in plaintext. Everyone already says “scope your tokens.” The part nobody says is to go find the permissions you can’t scope, and treat them as exactly the blast radius they are.

None of this shows from the outside, which is more or less the point. Two systems, one name, and a boundary that holds because somebody sat down and drew it instead of assuming it. It’s the least flashy thing in this whole series and probably the one I’d argue for the longest, because to me a homelab earns the word server on the day you start treating its blast radius like it’s real, instead of like a thing that only happens to other people.