Skip to main content

Glossary

Plain-language definitions of the core concepts used throughout the Meshr documentation. Each entry is short by design; follow the link under a term to read the full guide.

Mesh VPN​

A mesh VPN is a private network where every device connects directly to every other device through encrypted peer-to-peer tunnels, instead of routing all traffic through a single central server. Meshr builds this overlay automatically once each device runs the agent, so any peer can reach any other peer by name or by its mesh IP address regardless of the physical network it sits on.

See Mesh Overview.

WireGuard​

WireGuard is the modern, high-performance VPN protocol Meshr uses to encrypt every tunnel between peers. Each device holds a WireGuard keypair issued by the controlplane, and traffic between peers is encrypted end-to-end with keys that never leave the device. Because WireGuard runs in the kernel and uses a small, audited codebase, tunnels are fast to establish and cheap to keep open.

See Mesh Overview.

Peer​

A peer is any device running the Meshr agent that has joined your mesh — a server, laptop, CI runner, container, or IoT box. Every peer holds a WireGuard keypair issued by the controlplane and is assigned a stable address in the mesh CGNAT range (for example 100.64.0.0/10). Peers appear as Devices in the dashboard, where they can be inspected, renamed, updated, or removed.

See Peers.

Control plane​

The control plane is the coordination service that authenticates peers, distributes keys, and pushes access policies and DNS configuration to every agent. It orchestrates which peers may connect and how, but it never sees your data traffic — packets flow directly between peers, not through the control plane.

See Mesh Overview.

Relay node​

A relay node forwards encrypted traffic between two peers when a direct peer-to-peer connection cannot be established — typically because both sides sit behind restrictive NATs or firewalls. Traffic routed through a relay stays end-to-end encrypted, so the relay moves packets without being able to read them. Meshr uses cloud relays automatically when needed, and self-hosted deployments can run their own.

See Relay Nodes.

NAT traversal​

NAT traversal is the set of techniques that let two devices behind separate routers or firewalls form a direct connection. Meshr discovers each peer's public address and port mapping, then uses UDP hole punching to open a direct tunnel; if that fails it falls back to a relay node. The process is fully automatic and requires no port forwarding or manual firewall rules.

See NAT Traversal.

Mesh DNS​

Mesh DNS is the built-in name service that lets peers address each other by name instead of by IP. Every peer is automatically resolvable at a <name>.meshr address, so services can be reached by a stable, human-friendly name even as underlying IP addresses change. You can also publish custom A, AAAA, CNAME, TXT, and SRV records served by mesh DNS.

See DNS.

Split DNS​

Split DNS (split-horizon DNS) conditionally forwards selected domains to upstream or private resolvers without taking over a device's normal resolver path. It lets a peer resolve internal corporate domains through a nameserver group while everything else uses the device's usual DNS. A built-in guard blocks forwarding of public domains you don't own, preventing accidental interception.

See DNS.

Route (routed subnet)​

A route makes an off-mesh subnet — an office LAN, a cloud VPC, a home network — reachable from any peer, without installing the agent on every device in that subnet. Meshr advertises the subnet's CIDR across the mesh so peers can reach hosts like printers, a NAS, or a legacy database that can't run an agent themselves. Routes support high-availability failover across multiple gateway peers.

See Routes.

Gateway (gateway peer)​

A gateway is an ordinary peer that an admin has attached to a routed subnet, giving it the job of forwarding traffic between the mesh and that off-mesh network. It is not a special install mode or a separate binary — any agent becomes a gateway the moment it is bound to a route. Dedicating a small, always-on box to this single role keeps subnet routing reliable and free of competing workloads.

See Dedicated Gateway Appliance.

Setup key​

A setup key lets a device join the mesh without an interactive browser login, which is how headless machines — servers, CI runners, containers, IoT devices — are enrolled. Keys can be one-time or reusable, carry an optional expiry, and can mark the peers they register as ephemeral. The same key format powers Meshr's one-line installer.

See Setup Keys.

Device group​

A device group is a named bundle of peers that access policies can target as a single unit, so rules read "Group A can reach Group B" rather than naming individual peers. Groups are the primary building block of the access model and the single canonical way to bundle devices — access policies, SSH access, split-DNS scoping, and setup-key auto-assignment all select a device group.

See Device Groups.

Access policy​

An access policy is a single allow-or-deny rule that decides who on the mesh can talk to whom, defined by a source, a destination, a protocol and port scope, and a direction. The control plane evaluates policies against the live peer and group state and pushes the resulting allow-list to each agent's WireGuard configuration. A fresh organization starts fully open; creating the first policy switches it into selective mode, where only matched traffic is allowed.

See Access Policies.

Zero trust access​

Zero trust access (zero-trust network access, ZTNA) is a security model in which no device or user is trusted by default, regardless of network location — every connection is authenticated, authorized against policy, and encrypted before it is allowed. Meshr applies this continuously across the mesh, granting least-privilege access and encrypting and logging all traffic even between internal peers. The guiding principle is "never trust, always verify."

See Zero Trust Network Access.

mTLS​

Mutual TLS (mTLS) is a mode of TLS in which both sides of a connection present and verify a certificate, rather than only the server. Meshr uses mTLS for all communication between agents and the control plane: each device presents a per-device client certificate and the control plane presents a CA-signed server certificate, so both ends prove their identity. This prevents eavesdropping and impersonation of the control channel.

See mTLS & Certificate Management.

SSH certificate​

An SSH certificate is a short-lived credential, signed by your organization's certificate authority, that grants SSH access without distributing static public keys to authorized_keys files. Certificates encode the user's identity and allowed permissions, expire automatically, and can be revoked instantly from the dashboard. Meshr issues them on demand for both users and hosts.

See SSH Certificates.

Tunnel​

A tunnel exposes a local service to the internet through a public Meshr subdomain, without opening ports on your firewall or configuring a reverse proxy. HTTP tunnels publish a local web service at a *.tunnel.meshr.to URL and can be protected with basic, bearer, or custom-header authentication; TCP tunnels forward raw connections. All tunnel traffic is encrypted end-to-end through the mesh.

See HTTP Tunnels.