Webmesh is a simple, distributed, and zero-configuration WireGuard™ mesh solution for Linux, FreeBSD, macOS, and Windows. It allows for easily creating a mesh network between multiple hosts, and provides a simple API for managing the network. It is designed to be easy to use, and to work well with existing network infrastructure. For a more detailed introduction and extended documentation, please see the project website.
Webmesh is not a VPN, but rather a mesh network. It is designed to be used in conjunction with existing network infrastructure, and not as a replacement for it. It is also not a replacement for WireGuard™, but rather a way to manage a WireGuard™ mesh network. Connections are made into the network via direct links, over ICE (WebRTC) connections, or over LibP2P circuit relays. It differs from other WireGuard™ management solutions in that:
- It is designed to be distributed and extensible, relying on no single controller or database.
- The network is malleable and topology is governed by the user, not the controller.
- A plugin API is provided for adding additional functionality, such as a distributed database for storing the mesh state or additional authentication mechanisms.
- An application API is also provided for interacting with the mesh network, and is used by the CLI and GUI applications.
Detailed instructions can be found in the Getting Started guide on the project website. For examples of different topologies and the various features available, see the examples directory.
If you'd like to play with the project on Kubernetes, there is a work-in-progress Operator in the operator repository. It works fine on most clusters, including ephemeral docker-based ones, but is not yet ready for production use.
The Makefile contains several targets for building the project.
You can run make help to see all the available targets.
- GUI Application. In the works over here.
- Potential SaaS offering for those who don't want to run their own controllers or have a simple off-site backup of the mesh state.
Most other functionality that is provided by other similar projects already exists in the kernel or in other projects. For example, NAT64 and DNS64 have several ways of being configured, but could still be seen as a potential common use-case. There is a question as to how many of those things should be "auto-configured" by a node and how much should be left up to the user.
Contributions are welcome and encouraged. Please see the contributing docs for more information.
Join me on Discord or in the webmesh channel on the Gophers Slack.
The developers of rqlite for inspiration on managing a distributed database.
The incredible work done by the pion team for WebRTC in Go.
WireGuard is a registered trademark of Jason A. Donenfeld.
Become a Github Sponsor.
