Published5 min read

Split-Horizon Homelab: A Public Showcase on CloudFront, a Private Core at Home, and Zero Open Ports

How home-lab.net is planned so the public sees a fast static site on CloudFront, while the same domain at home or over WireGuard leads to a private Proxmox core—without opening a single port on the home router.

Note

Blueprint Status (Planned Target Architecture): The public side of home-lab.net is live today on S3 and CloudFront. The private side described here—the Proxmox services, the WireGuard relay, and the mail pipeline—is planned, and comes online after the current network and server consolidation.

Every homelab eventually runs into the same dilemma when you want to show it off: open ports on your home router and accept a permanent background hum of port scans, or hide everything behind a VPN where nobody can see what you’ve built.

For home-lab.net, I’m taking a third route: split-horizon. The same domain name leads to two completely different places depending on where you’re standing.


1. The Core Principles

  1. Zero open ports on the home router. No port forwarding, no UPnP, no inbound exceptions. The router drops everything that arrives uninvited. (Our NURO line actually has a real public IPv4 address, so forwarding would work. I’m choosing not to—it would publish our home IP and tie the design to a feature most Japanese lines don’t even offer.)
  2. A public showcase on the edge. Visitors to https://www.home-lab.net get a static site served from S3 and CloudFront: hardware specs, topology, and write-ups, with nothing that touches the house.
  3. A private core at home. On the home network—or on my phone over WireGuard—the same domain resolves to a Proxmox server in the closet, with the private services behind single sign-on.

2. Network Topology & Relays

3. Home: Proxmox VE Host (Planned)

2. AWS Tokyo Bridge (ap-northeast-1)

WireGuard On-Demand

SMTP 25

Tunnel dialled OUT from home

Outbound HTTPS pull

SMTP 587 relay

1. Public Internet

HTTPS

Public Visitor

CloudFront + S3 (Static Showcase)

Phones Away From Home

AlwaysRoute WireGuard Relay (Lightsail)

External Mail Senders

Amazon SES Inbound + Encrypted S3 Bucket

Amazon SES Outbound Relay

External Recipients

Caddy Reverse Proxy (Wildcard TLS)

Authelia SSO (Passkeys)

Unbound (Split-Horizon DNS)

Private Services: Start Page, SearXNG, Immich, Stalwart, GitLab

OpenZFS Storage

The trick in every arrow touching the house: the connection starts from inside. Nothing on the internet ever initiates a connection to the home router.

The Tokyo Bridge: WireGuard Relay & SES Mail

Two small AWS pieces in Tokyo do the work an open port would normally do:

  • The WireGuard relay (alwaysroute.com). The Proxmox host dials out a persistent WireGuard tunnel to a tiny, stateless Lightsail instance in Tokyo. Phones use WireGuard’s On-Demand rules: on mobile data or someone else’s Wi-Fi, they connect through the relay automatically; on our home Wi-Fi, the tunnel switches itself off. Only traffic for the homelab goes through the tunnel—everything else uses the normal internet connection. I’m spinning the relay out as its own project at alwaysroute.com, and wrote separately about designing its logo.
  • Mail through SES and S3. The domain’s MX record points at Amazon SES in Tokyo, which checks SPF, DKIM, and DMARC, then drops each message into an encrypted S3 bucket. At home, a small worker pulls new messages over outbound HTTPS and hands them to Stalwart, the local mail server. Outgoing mail goes back out through SES on port 587. If the homelab is down for a day, mail simply waits in S3. The full design is in the zero-port mail write-up, and the Umami analytics pipeline uses the same pattern.

3. The Private Core: One Proxmox Host

Instead of spreading services across several power-hungry machines—a lesson I learned the expensive way when I liquidated two-thirds of my server rack—the private side is planned around a single Proxmox VE host:

  • Caddy terminates TLS for *.home-lab.net using a wildcard certificate issued over DNS (Route 53 DNS-01), so nothing needs to be reachable from the internet to get a valid certificate.
  • Authelia puts one passkey login in front of every internal service.
  • Unbound answers *.home-lab.net with the local Caddy proxy for anyone at home or on the tunnel; everyone else gets the public CloudFront answer.
  • Private services: a browser start page, SearXNG for private search, Immich for photos, Stalwart and Roundcube for mail, and GitLab CE for code.
  • OpenZFS storage managed directly by Proxmox—no separate NAS appliance—with fast NVMe mirrors for databases and mail, and bulk storage for the photo library.

Local AI (ai.home-lab.net) isn’t part of this box. It’s a later phase, waiting on a dedicated low-power Mac Studio, for reasons that come down to idle watts and electricity prices.

The start page itself, and how one Astro codebase builds both the public site and the private one, deserves its own post—so I’ll leave it there for now.


Closing: Two Sites, One Name

From the outside, home-lab.net is a quiet static website. From the couch, it’s the front door to everything we run at home. The only things exposed to the internet are a CDN, a mail service, and a disposable relay in AWS—none of which are in our house.

It’s a bit more plumbing than forwarding ports 80 and 443 and hoping for the best. But it means the router at home can say no to everyone, all the time, and nothing breaks.

Ed Stuurman

About the author

Ed Stuurman

Infrastructure and reliability engineer based in Japan. Passionate about resilient systems, bare-metal hardware, cloud automation with Terraform, and all things homelab.

Contact

Thoughts or questions on this article?

Found a bug, tested a similar setup, or want to discuss the details? Drop a message below.

Emails are delivered directly to ed@stuurman.com.