easy-wg-quick: a shell script that writes WireGuard hub and peer configs

The problem: hand-assembling WireGuard keys, addresses and AllowedIPs

WireGuard itself has no notion of a client list. Each peer is a public key, a set of allowed addresses, and an endpoint, and the hub config has to repeat those blocks for every device. easy-wg-quick exists to remove that repetition. The README describes the topology it targets: the machine running the script becomes the hub, described as a VPN concentrator, and all other peers connect to it in a road warrior configuration. That is the shape most people want when they set up a personal VPN for a laptop, a phone and a home router. The script's job is narrow and explicit: generate usable configuration for a hub and one peer on the first run, and another peer configuration on each subsequent run. It is aimed at an operator who already knows they want WireGuard and does not want to write the key exchange and address bookkeeping by hand. It is not aimed at a fleet of hundreds of peers with an inventory system, and nothing in the material suggests it tries to be.

What one invocation actually does

Running the script with no arguments creates the hub configuration and one client. The sample output in the README shows the sequence of file checks it performs: no seqno.txt, so it creates one; no wghub.key, so it creates one; no wghub.conf, so it creates one. Then it prints the detected hub address in the form 10.13.1.140:51820 on wlp9s0, which tells you the address, the port and the interface it picked. The next run finds the existing hub key and config and only adds a client, which it names wgclient_10.conf by default. Passing an argument changes the client filename instead of the sequence number, so ./easy-wg-quick client_name produces wgclient_client_name.conf. The README notes that you can rename an already generated file manually with mv -vi wgclient_10.conf wgclient_name.conf, which implies the filename is not referenced from inside the hub config and is therefore safe to change. Secrets are materialised as files: the sample output and the clear instructions both refer to .key and .psk files, so the private key and preshared key live on disk in the working directory. That is the central operational fact about this tool, and it drives everything about how you should run it.

Getting it running: script, Docker, or Terraform

The direct route is a download and a chmod. The README gives wget https://raw.githubusercontent.com/burghardt/easy-wg-quick/master/easy-wg-quick followed by chmod +x easy-wg-quick, or a git clone of the repository. Dependencies are listed as /bin/sh, wg, wg-quick, awk, grep and ip, with qrencode optional for the QR codes that appear in the sample output. Package names differ by platform: wireguard-tools mawk grep iproute2 qrencode on Debian and Ubuntu, wireguard-tools gawk grep iproute qrencode on Fedora, RHEL and CentOS, net/wireguard-tools plus graphics/libqrencode on FreeBSD, and brew install wireguard-tools qrencode on macOS. If ip is missing, the README says you must set EXT_NET_IF and EXT_NET_IP in the script, or edit wghub.conf directly. There is a container image at ghcr.io/burghardt/easy-wg-quick, and the README's Docker example first writes the server IP to extnetip.txt with curl -4 ifconfig.co/ip, then runs docker run --rm -it -v "$PWD:/pwd" ghcr.io/burghardt/easy-wg-quick. The note attached to that example is worth reading twice: extnetip.txt must be populated that way, or manually, if you intend to use the generated configuration on the host rather than inside the container. Terraform code for Google Cloud Platform lives in a separate repository, tf-gcp-easy-wg-quick. The script also has four flags that matter in practice: -h for help, -i to write initial configuration files without creating a client, -d to download and install wg-quick (into /usr/local/sbin as root, or $HOME/.local/bin otherwise), and -u to replace the script with the latest release.

Fine tuning is environment variables, not a config file

The tuning surface is a list of documented switches rather than a settings file you edit once. The README names them individually: disabling external interface autodetection, disabling external IP address autodetection, disabling random port assignment, disabling randomly generated internal network addresses, setting the interface MTU, setting custom DNS, setting custom client AllowedIPs, choosing the firewall type, deciding whether PostUp and PostDown should enable and disable IP forwarding, enabling IPv6, enabling NDP proxy instead of the default IPv6 masquerading, redirecting DNS, traffic control, and persisting configuration with systemd. Two of those deserve attention. First, the defaults are randomised: port assignment and internal network addresses are random unless disabled, which is a reasonable choice for avoiding collisions but means two hubs built on the same day will not share a subnet. Second, NDP proxy is offered as an alternative to IPv6 masquerading, which is a real routing decision and not a cosmetic one. The -i flag exists precisely because these values are autodetected on the first run: you write the initial files, change what you disagree with, then run the script again with a client name to produce the final configuration.

It generates files, and it never cleans up after itself

The clearest limitation is stated in the README without hedging: to start over you must manually remove all *.bak, *.conf, *.key and *.psk files, and all *.txt files as well if you want the initial configuration options gone. The line that follows is blunt: this script does not remove anything. There is no revoke command and no peer removal path. If a device is lost, you delete its config yourself and edit the hub. The second limitation is the working directory. Keys, preshared keys, configs and the sequence file all land wherever you ran the script, and the Docker example mounts the current directory into /pwd, so the same is true in the container. Running this in a shared or backed-up directory puts private keys wherever that directory goes. Third, the script writes configuration but does not apply it: the README's own output ends with a note telling you to customize the Interface section of wghub.conf if required, and the section on using generated configuration is a separate step. If you want something that reconciles live interface state with a desired peer list, this is the wrong tool, because it has no view of running state at all.

How it differs from wg-quick and from a WireGuard UI

The obvious comparison is with wg-quick itself, and the distinction is clean. wg-quick reads a finished .conf file and brings the interface up or down; it does not create keys, assign addresses, or write peer blocks. easy-wg-quick produces the files that wg-quick consumes, and it can even install wg-quick for you through -d, which is a fair illustration of the layering. The other comparison is with web-based WireGuard management panels, which typically keep a database of peers, expose an HTTP interface, and can revoke a peer by deleting a row. easy-wg-quick keeps its state in a directory of files and a seqno.txt counter, and revocation is a manual file deletion plus a hub edit. The trade is real in both directions: the panel gives you a peer inventory and a revoke button, while the script gives you a dependency-light program you can read end to end and run over SSH on a router or a small VPS. If your peer count is small and changes rarely, the file-based model is simpler to reason about. If peers are added and removed regularly by more than one person, the absence of any removal command becomes a recurring chore.

Maintenance, releases and licence

The project is a single Shell script under GPL-2.0, and the repository shows recent tagged releases: v0.0.8, v0.0.9 and v0.0.10, with the most recent push in September 2026. The version numbers are still in the 0.0.x range, which is consistent with a small, stable-scope utility rather than a project promising interface stability. Upgrades are self-service: -u downloads the latest release of the script and replaces the original file. That is convenient and also the main maintenance risk, because the script you are running is the file being overwritten, so keeping a copy of the version you validated is a reasonable precaution. On licensing, GPL-2.0 is a copyleft licence with obligations that attach when you distribute the software or a derivative, not when you run it on your own hub; the README links to the full text in the repository. The script also downloads wg-quick from the official WireGuard GitHub mirror under -d, and that component carries its own licence, which is a separate consideration from this project's. Nothing here is legal advice, and if you plan to redistribute a modified copy you should read the licence text rather than rely on a summary.

Editorial conclusion

Adopt easy-wg-quick if you are comfortable with a shell script writing files in your current directory and you want hub plus peer configs, including QR codes for Android and iOS, without hand-editing keys and AllowedIPs. Do not adopt it if you expect a service, a state database, or a tool that removes peers for you: the README states plainly that the script does not remove anything, and clearing state means deleting the *.conf, *.key, *.psk, *.bak and *.txt files yourself. Before trusting it, run ./easy-wg-quick -i once and inspect the generated wghub.conf and the text files it writes, because that is where autodetected interface, IP and port values land and where you would override them.

Official sources

1. burghardt/easy-wg-quick on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases