Netmaker: WireGuard Automation With a Server in the Middle
Netmaker makes networks with WireGuard. Netmaker automates fast, secure, and distributed virtual networks.
At a glance
- What is it?
- Netmaker is a Go control plane that turns WireGuard into a managed overlay network with a web UI, access control lists and per-platform clients. It is a good fit when you have many peers and no appetite for hand-editing wg0.conf, and a poor fit when a single static tunnel is all you need.
- Who is it for?
- Adopt Netmaker if you are running more than a handful of WireGuard peers, need an admin UI, OAuth login and ACLs over a mesh, and are willing to operate a public control server. Do not adopt it if your requirement is one static tunnel between two hosts, or if you cannot expose a control endpoint to the internet.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Netmaker picks up where wg-quick puts it down
WireGuard itself is a small kernel module and a config file format. It has no notion of a network. Every peer is a public key, an endpoint and a list of allowed IPs, and every new node means editing that list on the machines that need to reach it. That is fine for two hosts. It gets tedious at ten, and it becomes an operational problem when the hosts are spread across clouds, data centres and edge devices that change address.
Netmaker's answer is a control server that owns the peer list and pushes it out. The README frames the project as "WireGuard automation from homelab to enterprise" and lists three columns of capability: create (WireGuard networks, remote access gateways, mesh VPNs, site-to-site), manage (admin UI, OAuth, private DNS, access control lists) and automate (Linux, Docker, Mac, Windows). The audience is anyone who wants the kernel data path of WireGuard but not the manual key and endpoint bookkeeping. That includes homelab operators running a handful of boxes and platform teams wiring clusters together.
The project is written in Go, ships a default branch called develop, and its most recent release in the supplied material is v1.7.0 from August 2026, following v1.6.0 in June and v1.5.1 in March. That cadence suggests an actively maintained codebase rather than a frozen one, though release frequency on its own says nothing about the quality of any given release.
Control server, clients, and peers that still talk directly
The architecture the repository describes has two halves. The server (the Netmaker component, distributed as a Docker image under gravitl/netmaker) holds the network definition: which nodes belong to a network, their keys, their addresses, the ACL rules and the DNS entries. The client (netclient) runs on each participating machine, enrols with the server, receives its configuration and applies it to the local WireGuard interface.
What matters for performance is what does not pass through the server. Once peers have exchanged keys and endpoints, the traffic between them is WireGuard traffic, which on Linux is handled by the kernel module. The README's claim is that "Kernel WireGuard offers maximum speed, performance, and security." The control server is involved in membership changes, not in the data path, which is the same split that makes any overlay network viable at scale.
The feature list also names remote access gateways and site-to-site links alongside plain mesh. Those are different topologies built from the same primitives: a gateway node advertises a subnet into the overlay so that clients can reach networks they are not directly a member of. Private DNS and access control lists sit on top, so a node can be given a name rather than an IP, and traffic between nodes can be permitted or denied by policy rather than by the allowed-IPs list. Whether the ACL implementation is enforced at the client or at the gateway is not something the README states, and it is worth checking in the docs before you rely on it as a security boundary.
Getting a server up: the quick install script and its preconditions
The self-hosted path in the README is deliberately short. You need a cloud VM running Ubuntu 24.04 with a static public IP. You open inbound 443 and 51821, both TCP and UDP, in the cloud firewall, and for simplicity allow all outbound TCP and UDP. Then you run:
sudo wget -qO /root/nm-quick.sh https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh && sudo chmod +x /root/nm-quick.sh && sudo /root/nm-quick.sh
The README marks DNS as recommended rather than required: set a wildcard subdomain such as *.netmaker.example.com pointing at the VM's public IP. That wildcard is what lets the server hand out per-node names without you adding a record for each one, so treat it as effectively mandatory if you want the private DNS feature to be useful.
There is a second install path for what the README calls the PRO version, linked to a separate documentation page (netmaker-professional-setup) rather than described in the repository. The README does not enumerate what the professional build adds, so the only honest statement is that the split exists and you should read that page before choosing. A managed SaaS option is also offered at account.netmaker.io for people who do not want to run the server at all.
The README points to a walkthrough and a getting-started guide for configuring networks after installation. It does not list the server's own configuration keys or environment variables, so anything beyond the quick install script has to come from those docs.
The licence is not a single licence, and that decides how you can use it
The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not classify the file automatically. The README explains why. Content under a pro/ directory, if that directory exists, falls under the terms in pro/PRO_LICENSE. Third-party components keep their original licences. Everything outside those categories is offered under Apache License 2.0.
That is a mixed-licence repository, and the practical consequence is that you cannot describe Netmaker as "Apache 2.0" without qualification. If you are evaluating it for a commercial deployment, the file that matters is LICENSE.md, which the README says collects the details, plus pro/PRO_LICENSE if that directory is present in the tree you are using. I am not in a position to interpret those terms, and nothing here is legal advice; the point is simply that the licence question has a specific answer in this repository and it is not the badge on the sidebar.
The maintenance picture is similarly split. The repository is not archived and the last push recorded is September 2026, with v1.7.0 landing at the end of August 2026. Upgrade cost is where self-hosted control planes usually bite: the server and every netclient need to be compatible, and a control plane that pushes configuration to clients means a server upgrade can change what clients are told to do. The README gives no upgrade procedure, no version compatibility matrix and no rollback instructions, so a team running this in production should establish its own before the first upgrade rather than after.
When Netmaker is the wrong tool
The clearest failure mode is scale of need, not scale of network. If your requirement is a single tunnel between two machines, or a fixed set of five hosts that never change, Netmaker adds a server, a database, a web UI, a DNS dependency and a client agent to solve a problem you do not have. A wg-quick config file copied to both ends is simpler, has no control plane to be unavailable and no upgrade path to manage.
The second constraint is that the control server is a public endpoint. The quick install opens 443 and 51821 to the world. If your environment cannot expose an inbound control port, or if your threat model treats a central server holding every node's keys as unacceptable, the architecture is working against you. The README does not describe an air-gapped or fully peer-to-peer enrolment mode, so assume the server is required.
The third is platform coverage. The automate column lists Linux, Docker, Mac and Windows, and the community projects list includes an OpenWRT netclient packager and a Podman setup, which implies that support outside the main four is community-maintained rather than first-party. If your fleet includes routers or unusual distributions, verify that a netclient package exists for the exact target before you design around it.
Finally, the feature table is a checklist, not a specification. OAuth, private DNS and ACLs are all listed without detail. A checklist entry tells you the capability is intended, not how it behaves under load, what happens when the server is unreachable, or whether ACLs are enforced where you need them enforced.
How it differs from plain WireGuard and from Tailscale
Plain WireGuard is the baseline and the honest alternative for small setups. The difference is not the tunnel, it is who maintains the peer list. WireGuard gives you a config file and expects you to keep it current; Netmaker keeps it for you and distributes it. If your peer set is static and small, the automation has nothing to automate.
Tailscale is the other comparison worth making, and the difference is architectural rather than cosmetic. Tailscale runs a coordination server you do not operate, with an identity provider tied to its own account system, and its clients are built around that service. Netmaker is self-hosted by design: the README's primary quick start deploys the server on your own VM, and the SaaS option exists alongside it rather than replacing it. If your reason for wanting an overlay is that you do not want a third party in the path, self-hosting the control plane is the whole point, and Tailscale's model is the opposite of that.
There is also a WireGuard UI comparison to draw. A UI that edits wg-quick files on one host manages one host. Netmaker manages many hosts from one place, which is a different product category even though both put a web page in front of WireGuard. The community project list in the README includes a Golang GUI and a CoreDNS plugin, which suggests the ecosystem around Netmaker is small enough that you should expect to integrate pieces yourself rather than find a plug-in for everything.
Editorial conclusion
Adopt Netmaker if you are running more than a handful of WireGuard peers, need an admin UI, OAuth login and ACLs over a mesh, and are willing to operate a public control server. Do not adopt it if your requirement is one static tunnel between two hosts, or if you cannot expose a control endpoint to the internet. Before committing, verify three things: the actual licence text for the pro/ directory and everything outside it, whether the netclient package covers your OS and kernel, and whether your DNS plan supports the wildcard subdomain the quick install expects.
Community notes