NEW Self-serve signup is live. Free for 2 machines, forever. ₹349/machine/month after. See pricing →
Quickstart Docs Compatibility Blog Pricing
Sign in Sign up free
/ docs

How it actually works.

A high-level overview of the architecture, the standard WireGuard configuration MeshWG generates, and the end-to-end testing that verifies every claim on this site before each release.

/ 01 ARCHITECTURE

Architecture in five claims.

MeshWG keeps things simple. Here are the core principles that define how it works, and why it's different.

01 CONTROL

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.

  • Single managed hub
  • Consistent access rules
  • No direct machine discovery
02 ISOLATION

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.

  • Organization-level isolation
  • No overlapping conflicts
  • Your network stays private
03 POLICY

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.

  • Enforced at the edge
  • No bypass, no race window
  • Instantly applied
04 SECURITY

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.

  • Encrypted at rest
  • Requires unlock secret
  • Keys shown once, never stored
05 INTERNET

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.

  • No internet routing
  • Private network only
  • You stay in control
/ 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 | Configuration 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 keep it simple. No gimmicks, no magic. Here's what MeshWG doesn't do.

01
We don't ship firmware.
The router runs whatever it normally runs.
02
We don't install an agent on your devices.
The WireGuard implementation is the one already in the device.
03
We don't invent a new tunnel protocol.
It's WireGuard, RFC-style.
04
We don't intercept your traffic.
It's WireGuard-encrypted end to end.
05
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.

Test
What is verified
Test
What is verified
Sign-in + abuse controls
Login, session, CSRF, and rate-limit protections all behave as advertised.
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.