Docs — MeshWG

/ 01 architecture

Architecture in five claims.

One place where policy is decided

All overlay traffic between your machines is routed through a single managed hub — the one place where access rules are applied. Your machines don't need to discover each other directly; they reach the hub, and the hub decides who reaches whom.

Strict isolation between organizations

Each organization is fully isolated from every other organization on the service. Other organizations cannot see or reach your machines, even if they happen to use overlapping private IP ranges.

Policies apply before traffic reaches the destination

When you set a policy to deny, packets are dropped before they ever reach the destination machine. There's no software agent on your devices to bypass and no race window — the rule applies the moment you save it.

Server-side keys are encrypted at rest

The keys MeshWG holds on your behalf are encrypted at rest. The service cannot start at all if the unlock secret is missing. Per-machine private keys are shown to you once at creation and never persisted server-side.

No path to the public internet through MeshWG

MeshWG forwards your overlay traffic between your own machines only. There is no internet egress path through us — your devices continue to reach the internet through their own local network.

/ 02 the config we generate

Standard WireGuard. Nothing custom.

When you add a machine in the dashboard, MeshWG returns a wg-quick configuration that any WireGuard implementation accepts as-is. Below is the exact format.

# WireGuard config for machine "branch-mumbai"
[Interface]
PrivateKey          = <shown once at machine creation>
Address             = 10.100.0.2/16
MTU                 = 1420

[Peer]
# MeshWG hub for "acme-networks"
PublicKey           = <your MeshWG hub public key>
Endpoint            = vpn.meshwg.com:51820
AllowedIPs          = 10.100.0.0/16
PersistentKeepalive = 25

/ 03 what it doesn't do

The honest list of things MeshWG isn't.

— We don't ship firmware. The router runs whatever it normally runs.
— We don't install an agent on your devices. The WireGuard implementation is the one already in the device.
— We don't invent a new tunnel protocol. It's WireGuard, RFC-style.
— We don't intercept your traffic — it's WireGuard-encrypted end to end.
— We don't retain per-machine private keys. They're shown to you once at creation, then gone.

/ 04 how we verify it works

Every release is tested end-to-end against real traffic.

Before any release ships, an automated end-to-end test drives the live service the same way a customer would, and measures real packet behaviour — not just API responses. If anything on this page regresses, the deploy fails and the change doesn't go out.

Sign-in + abuse controls

Tunnel handshake

Two real machines complete a WireGuard handshake against the live service

Policy enforcement

When a deny rule is set, the traffic it blocks really stops flowing

Org-to-org isolation

One organization cannot observe or reach another organization's traffic

Concurrent device adds

Many devices added in parallel never collide on an overlay address

Policy churn soak

Dozens of allow/deny flips in a row; every transition lands correctly

Self-healing

Forcefully damage internal state — connectivity recovers automatically

Onboarding burst

Many organizations created at once; each gets a working mesh

Live traffic during change

Toggle policies while traffic flows; what is denied is dropped, what is allowed gets through

No internet egress

External destinations are unreachable through MeshWG by design

Edge-case names

Long names with special characters onboard cleanly with no leftover state

Delete-org cleanup

Deleting an organization removes everything that belonged to it, with no orphans

Each test measures real packet behaviour and real handshakes — not just status codes — so the claims on this page stay true release after release. Want to see a recent test transcript? Email hello@meshwg.com and we'll share the latest run.