hwdsl2/wireguard-install: A Bash Installer That Puts a WireGuard Server on Eight Linux Families

The gap between installing WireGuard and having a working VPN

WireGuard ships as a kernel module and a userspace tool. What it does not ship is an opinion about how your server should be configured. After installing the packages you still generate server and client keypairs, write an interface config, decide on an address range, pick a port, set up NAT so client traffic reaches the internet, choose DNS resolvers to push to peers, and produce a config file for every device you want to connect. Each step is short. Together they are the reason many people never finish.

This project targets that gap. The README describes it as a script that will "let you set up your own VPN server in just a few minutes, even if you haven't used WireGuard before." The audience is someone with a cloud server, VPS or dedicated machine running Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS, Fedora, openSUSE or Raspberry Pi OS, who wants a private endpoint rather than a commercial VPN subscription. The script also generates profiles for Windows, macOS, iOS and Android, and prints QR codes for mobile setup, so the client side is covered without hand-editing configs on a phone.

What the script actually does during an install

The repository is a single Shell entry point, wireguard-install.sh, plus documentation under docs/. There is no daemon, no web UI and no state database. The script is the whole product.

During a run it collects a small set of inputs: the server's DNS name or address, the UDP port, the DNS server pushed to clients, and the name of the first client. It then installs WireGuard from the distribution's package manager, writes the server interface configuration, generates the server keypair and the first client keypair, and emits a client configuration file. The README lists sysctl optimisation as a feature, which means the script adjusts kernel network parameters rather than leaving defaults in place. It also advertises dual-stack IPv4 and IPv6 support for clients.

Client management is handled by re-running the same script with flags rather than by a separate tool. The usage block documents --addclient, --listclients, --removeclient and --showclientqr, plus --uninstall to remove WireGuard and delete all configuration. That design keeps the mental model small: one file, downloaded once, invoked repeatedly. It also means the script must be able to reconstruct enough state from the filesystem to know which clients exist, which is why removing a client or uninstalling prompts for confirmation unless you pass -y or --yes.

Install commands, flags and the here-document trick

The README gives a download step and two install paths. Download first:

wget -O wireguard.sh https://get.vpnsetup.net/wg

Then either unattended:

sudo bash wireguard.sh --auto

or interactive:

sudo bash wireguard.sh

The interactive path lets you customise the server DNS name, UDP port, client DNS server and first client name. The unattended path accepts the same values as flags: --serveraddr takes a fully qualified domain name or an IPv4 address, --port takes 1 to 65535 with a default of 51820, --clientname defaults to client, and --dns1 and --dns2 set the resolvers pushed to the first client, with Google Public DNS as the documented default.

For repeatable installs the README documents feeding answers through a Bash here document, with an example that passes a port, a client name, a count and a confirmation. The README itself warns that install options may change in future versions, which is the honest caveat for anyone scripting this in provisioning automation. Client operations after install use the same downloaded file: sudo bash wireguard.sh --addclient [name], --listclients, --showclientqr [name], --removeclient [name], and --uninstall. On servers behind an external firewall, the README states that you must open the chosen UDP port yourself, and names UDP 51820 as the default.

Where the installer model breaks down

The script is a one-shot configurator, and that shapes its limits. There is no documented way to declare desired state and reconcile it. If you edit the generated interface config by hand, nothing tracks that change, and a later --removeclient or --uninstall run operates on whatever it finds on disk. On a fleet, that means running the script on each host and trusting that each run produced the intended result.

Peer configuration is also coarse. The documented options cover DNS resolvers and a client name. There is no flag for per-client allowed IPs, a custom address, or per-peer routing rules. If you need one client to reach only a specific subnet, or you want to hand out addresses from a range you control, the script's defaults will not express that and you will be editing the config files it wrote.

There is no audit trail. The tool writes files and restarts the interface; it does not log who added which peer or when. On a multi-admin server that is a real gap. And the supported platform list is explicit: eight distribution families plus Raspberry Pi OS. A distribution outside that list is unsupported, not merely untested. Finally, the README's own note that install options may change between versions is a direct warning against pinning automation to the here-document interface without reviewing the script after each update.

How this differs from wg-easy and from doing it by hand

The closest thing to a direct alternative in the same problem space is wg-easy, which puts a web interface in front of WireGuard and stores peers in a small database, so adding or revoking a client is an HTTP action rather than a shell invocation. That difference matters operationally: wg-easy gives you a persistent view of peers and a UI a non-shell user can operate, at the cost of running an extra service with its own attack surface and its own upgrade path. This script has no listening service beyond WireGuard itself, which is a smaller surface, but it also has no state you can query except by reading config files.

The other alternative is the manual route: install the wireguard package, write /etc/wireguard/wg0.conf yourself, run wg-quick up wg0, and generate peer keys with wg genkey and wg pubkey. That is more work per server and more room for mistakes, but every value is explicit and the config is a file you can put in version control and review in a pull request. The script is best understood as a generator for exactly that file, plus the sysctl and NAT pieces people usually forget. If your workflow already treats server configuration as code, the script's output is the useful part and its interactive layer is not.

Licence, updates and what you are taking on

The project is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. If you fork the script or vendor it into an internal repository, keep that notice intact. Nothing here is legal advice; if licence terms matter to your organisation, have someone qualified read the MIT text against your distribution model.

The material retrieved lists no releases, so there is no tagged version to pin. Updates arrive as commits to the master branch, and the recommended download URL, https://get.vpnsetup.net/wg, serves the current script rather than a fixed revision. That combination means the version you run tomorrow may differ from the one you ran today, and the README's warning about changing install options applies to the here-document path in particular. If you depend on unattended installs, fetch the script, record its hash, and review the diff before replacing it.

Maintenance on the server side is mostly the distribution's WireGuard package plus your own kernel upgrades. The script writes configuration once and does not run as a daemon, so it adds no ongoing process to monitor, but it also will not repair drift. The README notes that after setup you run the script again to manage users or uninstall, and points to docs/clients.md for configuring devices and to docs/vpn-book.md for further reading.

Editorial conclusion

Adopt it if you administer one or a few VPS instances on the listed distributions and want a WireGuard endpoint configured in one command, with client profiles and QR codes generated for you. Do not adopt it if you need per-peer policy, an audit trail, or configuration managed as code across many hosts; the script is a one-shot installer, not a control plane. Before running it, read wireguard-install.sh end to end, confirm your kernel and distribution are on the supported list, and check whether an external firewall already filters UDP 51820, because the script cannot open ports on a cloud security group for you.

Official sources

1. hwdsl2/wireguard-install on GitHub
2. Issues
3. License: MIT
4. README