WiseHosting
Networking

Networking

How traffic flows between users, the control plane, and worker hosts — and why each hop looks the way it does.

WiseHosting has three distinct traffic planes. Keeping them straight is the easiest way to reason about firewalls, TLS, and what is allowed to talk to what.

PlaneWho talksWhereEncrypted by
User → DashboardBrowser ↔ control planePublic internet → Cloudflare → CP :8081Cloudflare TLS (HTTPS)
End user → AppBrowser ↔ proxy server → worker containerPublic internet → proxy server 192.99.14.173 (Traefik :443) → WireGuard → worker container portLet's Encrypt TLS on proxy server; WireGuard between proxy and worker
Control plane ↔ WorkerCP ↔ worker agentPrivate WireGuard mesh 10.50.0.0/24 over UDP 51821WireGuard (Curve25519 + ChaCha20-Poly1305)
Proxy ↔ Control planeProxy Traefik ↔ CP HTTP providerWireGuard mesh 10.50.0.0/24WireGuard

The third and fourth planes never cross the public internet as plaintext — they ride the self-hosted WireGuard tunnel. That includes worker registration, JWT refresh, the WSS hub, the proxy Traefik config polls, and the actual forwarded app traffic between proxy and worker containers.

Why these planes?

Each plane has a different threat model. User-facing dashboard TLS lives at Cloudflare's edge. End-user app TLS is handled by Let's Encrypt on the proxy server — apps get real certificates automatically, including for user-supplied custom domains. Worker control traffic and app forwarding live on a private WireGuard mesh, so /v1/workers/* and /v1/traefik/* never need to be publicly reachable. Cloudflare WAF still drops public hits to those paths as belt-and-braces.

On this page