Friday, April 3, 2026
The Invisible Backbone
The only way to manage someone else's machine is if you can protect it. But to actually run a VPS — provisioning, deployment, updates, monitoring — you need full access. Those two things are in tension; you can't have both over a public network.
Going in through the front door means open ports, exposed SSH, firewall rules you hope the customer hasn't changed. That's not management; that's hoping for the best.
So you build an overlay network. One that connects your control plane to every managed machine without touching the public internet. For what strackt does, it's not optional — it's a necessity.
Why Nebula
We were using Tailscale before this. Tailscale is a great product — really good at building networks where you invite people, collaborate with a team, coordinate access through a dashboard. But it's designed around that model; it's not built for a central control plane orchestrating hundreds or thousands of nodes. And cost-wise, that scales in the wrong direction for us.
Nebula is different. It was built at Slack for exactly this use case — a large number of nodes, centrally orchestrated. It's open source, now maintained by Defined Networking, and built on the Noise protocol framework (the same cryptographic foundation as WireGuard, but an independent implementation). Simple infrastructure, extremely robust.
Every node gets a signed certificate that defines who it is and who it can talk to. Groups, firewall rules, access — all baked into the cert itself. No central authority needs to be online for two nodes to authenticate each other; they just verify each other's signatures.
The thing that makes this a pretty natural fit is that strackt is already a provisioning tool. Certificate access and key rotation on those machines? Just part of the normal lifecycle. It's not extra work; it's the work we were already doing.
What this means for your server
When you connect a server to strackt, it joins the overlay automatically. We configure it, keep the certificates rotated, keep it secure. You don't interact with any of this.
All traffic between your server and our control plane goes through the overlay. Your machine is reachable by us and invisible to everything else. You can close every public port, including SSH. The attack surface drops to pretty much nothing.
For now, this is the foundation that makes strackt's operational model possible. But it's also what future features build on — load balancing across servers, dedicated database servers, multi-server deployments. We're not building throwaway plumbing; this is the backbone.
Cross-provider VPC
This started as infrastructure we needed for ourselves. But the same network that connects your servers to our control plane can also connect your servers to each other.
Enable it, and we reconfigure the certificates so your machines are allowed to communicate over the overlay. That's it. Your server at Hetzner can reach your server at DigitalOcean on a private address, peer-to-peer. They don't need to be at the same provider, in the same datacenter, or on the same network. They just talk.
The obvious use case: database on one server, application on the other. Point your app at the overlay IP, and the connection is encrypted end-to-end. No public database ports, no firewall juggling, no provider-specific VPC that locks you into one platform.
Two birds, one stone.
We built this because we had to. You can't reach servers securely over the public internet. So we built the plumbing.
Turns out that plumbing is pretty useful for everyone. Cross-provider VPC, private addresses, encrypted connections between your machines — all from infrastructure that was already there. The best features are the ones that fall out of good architecture.