The Self-Healing Homelab: Architecting a Hybrid Cloud Between Helsinki and Kazakhstan

Every homelab tutorial assumes the same starting condition: a residential connection with a routable public IP, or at worst a router you can port-forward through. Running from Atyrau, Kazakhstan gives you neither. The ISP hands out addresses behind carrier-grade NAT, the routing path out of the region is long and occasionally lossy, and the power grid has opinions about uptime that a UPS can only argue with for so long. None of that is a reason to run a smaller lab. It's a reason to stop treating "the lab" and "the internet-facing edge" as the same piece of infrastructure.

The hardware, unglamorously

The compute layer is mostly hardware that already existed for other reasons, repurposed rather than bought new:

• A high-end desktop originally built for gaming is now the heaviest hypervisor node — GPU included, since a few workloads want it.
• A pair of small-form-factor boxes (NUC-class) run the low-power, always-needs-to-be-up control-plane services.
• A dedicated NAS box, several drives wide, backs shared storage for everything else.

All three roles join a Proxmox VE cluster, which means the "gaming PC" and the NUCs are just nodes with different resource profiles, not different systems to manage.

hv-primary   (desktop, heavy compute, GPU passthrough)
hv-control   (NUC, control-plane services)
nas-01       (bulk storage, backs shared VM disks)

The Helsinki connection

None of that cluster is reachable from the public internet, on purpose. The public edge is a small, cheap, always-on Hetzner Cloud VM in Helsinki — chosen for the unglamorous reason that it has a real static IP, sits on a well-routed network, and costs less per month than a coffee. It has no local data of consequence. If it disappears, it gets rebuilt from Terraform in minutes.

The only thing connecting Helsinki to Kazakhstan is a Tailscale mesh. Every node — the cloud VM, the desktop hypervisor, the NUCs, the NAS — enrolls into the same private WireGuard network at boot. CGNAT stops mattering the moment neither side needs an inbound public port to find the other.

The request path

reader  ─▶  DNS  ─▶  Helsinki VM (public IP, TLS termination)
                          │
                    Tailscale tunnel (encrypted, NAT-agnostic)
                          │
                          ▼
                 home Proxmox cluster (private services)

A request never "arrives" at the homelab in the traditional sense. It arrives at Helsinki, and Helsinki forwards it over a tunnel that doesn't care whether the other end has a public IP at all. The home network could change ISPs, rotate its address hourly, or sit behind three layers of NAT, and the request path wouldn't notice.

The principle underneath it

The governing rule for every infrastructure decision here is the same one: private by default, reproducible by design, owned infra first — SaaS only when it's economical or meaningfully safer. The Helsinki VM exists because "be publicly reachable" is a job better done by a disposable cloud box than by a residential connection with none of the guarantees a public edge needs. Everything behind it stays exactly as private as it would if there were no internet connection at all.

Next post: the Helsinki gateway itself — reverse proxy, split DNS, and the exit-node setup that makes the tunnel side of this diagram actually work.