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

What easy-wg-quick actually produces

WireGuard itself ships no configuration generator. You write an [Interface] block for the hub, generate a key pair per device, then hand-assemble an [Peer] block for every client and paste it into every client config. easy-wg-quick automates that bookkeeping. The README describes the target topology as a hub that acts as VPN concentrator, with all other peers connecting to it, the classic road warrior shape. The audience is someone running WireGuard on a VPS, a home router or a small server who wants config files, not a control plane. The script is Shell, GPL-2.0, and the repository carries no homepage, so distribution is the repository itself plus a container image on ghcr.io.

How the generator works, run by run

The script takes no required arguments. The README states that the first run creates the hub configuration plus one client, and that any sequential invocation creates another peer configuration within the same hub. State lives in the working directory as files: seqno.txt tracks the peer sequence number, wghub.key and wghub.conf hold the hub material, and each client gets a wgclient_N.conf file. Passing an argument names the client instead of numbering it, so ./easy-wg-quick client_name produces wgclient_client_name.conf. The sample output shows the autodetection step in action: it prints the hub address as an internal address and port on a detected interface, for example 10.13.1.140:51820 on wlp9s0, and tells you to customize the [Interface] section of wghub.conf if required. That is the whole model. Files in, files out, no running process.

Installing easy-wg-quick on Ubuntu or any hub with wg

The README lists /bin/sh, wg, wg-quick, awk, grep and ip as dependencies on the hub, with qrencode optional for QR codes aimed at mobile clients. On Debian and Ubuntu the documented package set is wireguard-tools, mawk, grep, iproute2 and qrencode. Fedora, RHEL and CentOS use wireguard-tools, gawk, grep, iproute and qrencode instead. Once the tools are present, installing the script is a download and a chmod:

wget https://raw.githubusercontent.com/burghardt/easy-wg-quick/master/easy-wg-quick
chmod +x easy-wg-quick

A short URL, https://git.io/fjb5R, works as an alternative source, and git clone of the repository is the third documented route. The first real run is argument-free, and the README says to expect a hub config and one client from it:

./easy-wg-quick
./easy-wg-quick laptop

The first command creates the hub and a numbered client; the second creates wgclient_laptop.conf inside the same hub. If you would rather inspect and edit the autodetected values before any keys are written, the -i option writes the initial configuration to text files without creating a client or hub configuration, and you repeat the script with a client name afterwards. If wg-quick is missing from the host, -d downloads and installs it from the official WireGuard GitHub mirror for Linux, FreeBSD, OpenBSD or Darwin, into /usr/local/sbin when run as root and $HOME/.local/bin otherwise.

Running it in Docker, and the extnetip.txt requirement

The Dockerfile is Alpine based, installs wireguard-tools and libqrencode-tools, copies the script to /usr/bin/easy-wg-quick, sets /pwd as the working directory and declares it a volume, with the script as entrypoint. The README's run recipe populates a file first, because the container cannot see the host's external interface the way a native run can:

curl -4 ifconfig.co/ip > extnetip.txt
docker run --rm -it -v "$PWD:/pwd" ghcr.io/burghardt/easy-wg-quick

The README is explicit that extnetip.txt must be populated with the server IP through that curl command or manually when the generated configuration will be used on the host instead of inside the container. Skip it and the hub address in the generated config will not be the address your peers need. Terraform code for deploying the script on Google Cloud Platform exists in a separate repository, tf-gcp-easy-wg-quick, which the README links.

Fine tuning that decides whether the output is usable

The defaults are opinionated and several of them will not match a given host. Autodetection of the external interface and the external IP address can both be disabled, which matters when the hub sits behind NAT or when the detected interface is not the one carrying traffic. Random port assignment can be turned off, and so can randomly generated internal network addresses, so you can pin the tunnel subnet. MTU is settable, which is the usual fix for tunnels that connect but stall on large packets. Custom DNS and custom client AllowedIPs are both supported, the latter being how you choose between full-tunnel and split-tunnel clients. Firewall type is selectable, and the README covers whether PostUp and PostDown should enable and disable IP forwarding. IPv6 has its own switch, and there is an NDP proxy mode as an alternative to the default IPv6 masquerading. DNS redirection and traffic control are also documented. Persisting configuration with systemd is covered too, which is the point where the script's job ends and the host's job begins.

Where easy-wg-quick is the wrong tool

The script writes files and stops. It does not bring interfaces up, it does not watch them, and it does not revoke anything. The README states plainly that to start over you manually remove all *.bak, *.conf, *.key and *.psk files, and all *.txt files if you also want to remove the initial configuration options, because the script does not remove anything. Removing one peer therefore means deleting its config and editing the hub's [Peer] block by hand; there is no per-peer revoke command. The README also documents no rollback path and no dry-run mode, so a run mutates the working directory immediately. If you need a web interface, live peer status, or a service that keeps tunnels up across reboots without a systemd unit you write yourself, this is not that project. The README does not document what happens on a partial or interrupted run, which is worth knowing before you point it at a directory you care about.

easy-wg-quick compared with wg-easy

wg-easy is the comparison people reach for, and the difference is architectural rather than cosmetic. wg-easy is a server with a web UI: peers are managed through a browser, and the running service owns the WireGuard interface. easy-wg-quick is a generator: it emits wghub.conf and wgclient_*.conf, and everything after that is stock wg-quick and stock WireGuard. That makes easy-wg-quick easier to audit, since the artifact is a text file you can read, diff and commit, and harder to operate, since adding a peer means running the script on the hub and distributing the file yourself. The container image narrows the gap slightly by removing host dependencies, but it still produces files rather than a managed service. If your deciding factor is avoiding a long-running web service on the VPN host, easy-wg-quick is on the right side of that line. If it is not having to touch the server for routine peer changes, wg-easy is.

Maintenance, upgrade path and licence

The last push to master was on 2026-09-02, and the most recent release is v0.0.10 from 2026-06-17, following v0.0.9 and v0.0.8 at roughly monthly intervals earlier in the year. The version numbering is still 0.0.x, and the repository is not archived. The script carries a self-upgrade option: -u downloads the latest release and replaces the original file with the downloaded version, which is the documented upgrade path and worth noting because it overwrites the script in place, so any local edits are lost. The licence is GPL-2.0. If you redistribute the script, or ship it inside a product, the GPL-2.0 terms apply to that distribution; the repository's LICENSE file is the authoritative text and this is not legal advice. The container image inherits the same licence. For a single operator running the script on a personal VPS, the practical obligation is close to nil, but a managed offering that embeds it is a different question and worth raising with counsel rather than assuming.

Editorial conclusion

Adopt easy-wg-quick if you want plain WireGuard config files on disk and you are comfortable editing wghub.conf by hand, or if you want the same generation step inside a container with the ghcr.io/burghardt/easy-wg-quick image. Do not adopt it if you need a web UI, per-peer revocation, or a service that keeps interfaces up for you; the script only writes files and the README states it does not remove anything, so cleanup is manual. Before committing, verify that wg, wg-quick and ip exist on the hub, that extnetip.txt is populated when you run the container, and read the Fine tuning section to confirm the firewall and IPv6 defaults match your host.

Frequently asked questions

Official sources

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