Anywherelan (awl): a libp2p mesh VPN with SOCKS5 and a full-tunnel exit node

The problem awl solves: reaching your own machines without a coordination server

The README frames the target narrowly. awl is a peer-to-peer mesh VPN for connecting your own devices to each other at the IP level, from wherever they are. A laptop behind a NAT, a home server and an old phone each get a stable .awl address and can reach each other as if they were on the same LAN. The stated audience is selfhosters, groups of friends and small device fleets of roughly ten devices. The README says directly that it is not a replacement for commercial mesh VPNs in a team setting, because there are no ACLs, tags, SSO or admin dashboards. That sentence is the most useful thing in the document, because it tells you where the project believes its own boundary is. The listed use cases are concrete: SSH, RDP or VNC into a home or work laptop without port forwarding; reaching selfhosted services such as Nextcloud, Home Assistant or Bitwarden privately; routing traffic through a remote device as a SOCKS5 proxy; routing all traffic through a remote device as a full-tunnel exit node; LAN-style multiplayer gaming across the internet; and keeping an old Android phone reachable for apps that only run there, with scrcpy given as the example. The differentiator the README claims is the absence of a coordination server. Tailscale, Netbird and ZeroTier are named as excellent products, especially for teams, and awl is positioned as a different shape: peers find each other through libp2p's DHT and connect directly, and everything in the stack, clients, bootstrap nodes and relays, is open source. The argument for that shape is that there is no single endpoint an ISP or government can blackhole.

Inside the mesh: TUN, wintun, DHT discovery and circuit relays

The architecture combines two pieces. One is a virtual network interface: TUN on Linux, macOS and Android, and wintun on Windows. The other is a peer-to-peer networking stack built on libp2p. IP packets written into the awl interface are wrapped into libp2p streams and delivered directly to the addressed peer. That is the whole data path, and it explains why awl can carry arbitrary IP traffic rather than only proxied TCP: once the interface exists, the operating system routes into it. Transport is negotiated per connection, either QUIC with native TLS 1.3 or TCP plus TLS. Discovery is where the decentralization claim lives. On startup, awl announces itself in the libp2p DHT through community bootstrap nodes, and the bootstrap node repository is linked from the README as a separate project. To reach a peer, awl looks it up in the DHT and opens a connection directly. NAT traversal is delegated to libp2p, which the README says handles hole-punching for most NATs. When both peers sit behind restrictive NAT and no direct path is possible, traffic is forwarded through a libp2p circuit relay, and the README states that relays see only encrypted bytes. That relay path is the part to think about. The security section says bootstrap nodes and relays see only ciphertext, which is true at the payload level, but a relay still observes that two peer IDs are exchanging traffic and roughly how much. For a personal mesh that is usually acceptable. For someone whose reason for leaving a commercial provider is metadata exposure, it is a real consideration, and the README does not discuss it.

Identity without a certificate authority

Each peer has an ed25519 keypair, and the peer_id is the public key, so identity and authentication are not separate layers. There is no CA and no certificate to revoke. The practical consequence is that there is no revocation list to consult and no central authority to ask whether a key is still trusted. The README's trust model section states that peers must add each other, and the text supplied here is truncated at that point, so the exact mechanism for adding a peer and for removing one is not fully visible in the material. What can be said from what is present is that trust is pairwise and explicit rather than policy-driven. That is the same design decision that produces the missing ACLs: if there is no control plane, there is nowhere to put a group policy. The transport security is inherited from libp2p, and the README points at libp2p's own documentation for the mechanics rather than restating them. For an operator this means the security properties are only as good as the libp2p version pinned in the build, which is an argument for tracking releases rather than installing once.

Getting it running: install paths, the awl CLI and the config file

The README lists installation per platform. There is a web UI, an Android build distributed through F-Droid under the package name com.anywherelan.awl, a Windows tray application called awl-tray, a macOS build, a Linux desktop tray build also called awl-tray, and a Linux server build called awl. The split matters: the tray builds are for desktops where a user is present, and the plain awl binary is the one for a headless server. There is also a terminal-based client with a section of common examples, which is the path to take on a machine with no desktop session. Configuration has a documented file location and an example config in the README, so the keys you would edit are visible in the repository rather than only in source. The README does not reproduce that example in the excerpt available here, so the specific key names are not something this article can quote. Two features are configured rather than merely toggled. Using a device as a SOCKS5 proxy has its own section, and the v0.17.0 release notes mention a SOCKS5 performance boost alongside a Material 3 UI redesign. The full-tunnel VPN gateway, also called an exit node, has its own section, arrived in v0.18.0, and gained a Windows implementation in v0.19.0. If you are planning a deployment, the ordering of those releases tells you the exit node is the newest and least settled part of the product, and Windows support for it is newer still.

Where awl is the wrong tool

The README is unusually direct about limitations, and the platform notes section exists as a named part of the document, though its contents are not in the excerpt provided. The structural limitation is policy. No ACLs, no device tags, no SSO, no admin dashboards. In a team of five this is survivable. In a team of fifty it is not, because there is no way to express who may reach what, and no audit surface. The second limitation is scale. The README puts the target at roughly tens of devices. A mesh where every peer can reach every other peer is fine at that size and becomes a routing and key-management problem beyond it. The third is the relay fallback. If you are on a network restrictive enough that hole-punching fails for both peers, your traffic takes a hop through a community relay. That is a dependency on infrastructure the project does not operate as a paid service, and the README does not describe what happens to availability if community relays are sparse or overloaded. The fourth is the missing control plane itself, viewed from the other side. There is nothing to shut down from outside, which is the selling point, and there is also nothing to log into when you need to see the state of the fleet. Monitoring is a named section of the README, so some mechanism exists, but for a user expecting a dashboard the answer is that the project chose not to build one.

How it differs from Tailscale, Netbird and ZeroTier

The README names these three and describes the difference as a matter of shape rather than quality. The concrete distinction is the coordination server. In the commercial model, devices register with a control plane that holds the network map and the policy, and that control plane is what makes ACLs, tags and SSO possible. In awl there is no such component. Peers find each other through the libp2p DHT and connect directly, and the README presents this as making awl harder to block, because there is no single endpoint to blackhole. The trade is exact: you give up centralized policy management and you get an absence of a central point of failure or control. A second difference is the openness of the whole stack. The README states that clients, bootstrap nodes and relays are all open source, with no closed-source control plane, and links the bootstrap node repository as a separate project. A third difference is feature surface. The README concedes that awl has a smaller feature set than the commercial alternatives and that bigger features are in flight, describing the project as currently best at the thing it already does well. If your requirement is a managed network with per-user identity and a web console, the commercial products are the right answer and awl is not, and the README says so.

Licence, upgrades and what maintenance actually costs

awl is licensed under MPL-2.0, the Mozilla Public License 2.0. MPL-2.0 is a file-level copyleft licence, which in outline means modifications to covered files must be made available under the same licence while larger works that combine covered files with separate files can be distributed under other terms. That is a general description of the licence family and not legal advice; if you intend to redistribute a modified awl or embed it in a product, read the LICENSE file in the repository and take your own advice. For most readers the practical effect is that self-hosting and internal use raise no distribution question at all. Upgrade cost is where the release history is informative. The three most recent releases land roughly two months apart, v0.17.0 in April 2026, v0.18.0 in June 2026 and v0.19.0 in July 2026, and each carries a headline feature rather than only fixes: a Material 3 UI redesign and SOCKS5 performance work, then the full-tunnel exit node, then the Windows implementation of that exit node. A project moving at that pace with the version still at 0.x means configuration and behaviour can shift between releases, and the README has a dedicated upgrading section, which suggests upgrades are a documented operation rather than a drop-in replacement. The reproducible builds section is relevant to maintenance too: if you verify builds, that property is worth checking on each release rather than assuming it holds. Budget time for reading release notes before upgrading a headless server, because the awl binary on a remote machine is the one you least want to lose.

Editorial conclusion

Adopt awl if you are a selfhoster or a small group of friends who want IP-level reachability between your own machines without a coordination server, an account, or a control plane that someone else can switch off, and if you accept that there are no ACLs, tags or SSO. Do not adopt it if you need policy management across a team, or if a relay hop in the data path is unacceptable for your threat model. Before committing, verify three things on your own hardware: that awl-tray or the Android build reaches your peers with a direct path rather than a community relay, that the built-in DNS resolves a peer name such as work-laptop.awl on every platform you use, and that the wintun driver installs cleanly on your Windows version.

Official sources

1. anywherelan/awl on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases