Insights · Managed Services
The Sovereign Edge: One Address, Three Traffic Classes
A clean edge design behind a single public address — HTTPS demultiplexed by SNI, real-time voice routed directly, and game traffic on its own ports. Why the boundary is one of the most important things you own.
The edge — the boundary between your infrastructure and the public internet — is one of the most consequential things a sovereign operator owns. Get it wrong and it becomes either a security liability or a bottleneck. Get it right and adding a new service, or taking one public, becomes a one-line change.
We run multiple ventures behind a single public address. Here is how three very different kinds of traffic share one front door without stepping on each other.
One address, one port 443, SNI decides
The first constraint is physical: a single public address has exactly one TCP port 443. You cannot send it to two backends. So the rule is simple — all web HTTPS arrives at one reverse proxy, and that proxy is the single point that decides where each connection goes.
It decides using SNI — the server name the client announces at the start of the TLS handshake. Crucially, our proxy does not terminate TLS for these sites. It reads the requested name from the handshake and passes the raw encrypted stream through to the correct backend, which presents its own certificate. This SNI passthrough model means:
- The edge holds no private keys for the sites behind it. Each backend owns its own certificate. Smaller blast radius, cleaner sovereignty story.
- Adding a site is adding one routing rule: “this server name goes to that backend.” Nothing else changes.
- Promoting a site from internal staging to a public domain is editing that same one line — swap the staging name for the final name, swap the cert. No rebuild of the site, no re-architecture.
That last property is a design goal we hold ourselves to everywhere: the difference between a staged site and a live one should be a configuration change at the edge, never a code change in the application.
Real-time voice bypasses the proxy on purpose
Voice does not belong behind a web proxy, and we route it accordingly. SIP signaling and RTP media travel over UDP, which has no SNI to switch on, and they are latency-sensitive in a way web requests are not. A general-purpose proxy would add latency and, worse, can mangle the addressing that voice protocols carry inside their own messages.
So real-time voice traffic is mapped directly to dedicated addresses on the voice cluster, on its own ports, never touching the web proxy. The components that handle signaling and media are built for exactly that job and handle it natively. Three benefits fall out: the voice edge stays a single coherent design, it shares no proxy with anything else, and the rest of the platform consumes it as a fixed, read-only contract.
Game traffic gets its own lane
Multiplayer game servers are a third class again — UDP, on their own reserved ports, mapped one-to-one to backends. They get their own lane at the edge rather than being forced through a model designed for web or for voice.
Why the discipline pays off
The shape — HTTPS demultiplexed by SNI, voice routed directly, game traffic on its own ports — means each class of traffic takes the path that actually suits it, and the edge stays comprehensible. There is one place that web routing lives, one place that voice exposure lives, one place that game ports live.
And every public exposure passes through a governed approval before it goes live. The edge is not just where traffic enters; it is where the decision to let traffic enter is made deliberately, and recorded. Owning that boundary — really owning it, down to the routing rules — is what makes “sovereign” mean something at the perimeter, not just in the datacenter.
networkingedgetraefiktlsarchitecture