/ docs

MeshWG Documentation

Learn how MeshWG's managed WireGuard mesh VPN architecture works. Explore the standard WireGuard configuration, zero-trust policies, and end-to-end testing.

/ 01 GETTING STARTED

Getting Started

MeshWG provides a hosted control plane for standard WireGuard, making it easy to build a zero-trust mesh network. The fastest way to begin is to Follow the MeshWG Quickstart.

/ 02 HOW MESHWG WORKS

How MeshWG Works

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
/ 03 CONFIGURATION

Configuration: Standard WireGuard

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
/ 04 WHAT IT DOESN'T DO

What MeshWG Doesn't Do

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.
/ 05 SECURITY AND VERIFICATION

Security and Verification

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.

/ 06 ROUTER SETUP

Router Setup & Compatibility

You can deploy MeshWG directly onto supported network edge devices for transparent site-to-site connectivity. View supported WireGuard routers and devices to find compatible hardware from TP-Link, MikroTik, Ubiquiti, and more.

/ 07 TROUBLESHOOTING

Troubleshoot Connectivity Issues

If a machine cannot connect to your MeshWG network, verify the following configuration basics:

01
Check the Endpoint
Verify that your WireGuard peer configuration correctly points to the MeshWG endpoint (e.g. vpn.meshwg.com:51820). If your local network blocks outbound UDP on port 51820, the handshake will fail.
02
Check AllowedIPs
Ensure the AllowedIPs field in your configuration matches the overlay subnet assigned to your organization (e.g. 10.100.0.0/16).

For more comprehensive diagnostic steps, read our guide on Why Your VPN Keeps Disconnecting, or dive into WireGuard NAT Traversal for complex Carrier-Grade NAT environments.