wireguard-install: one script, three jobs, and no record of what it changed

The whole repository is one shell file and two documents

Three entries sit at the root:

LICENSE.txt
README.md
wireguard-install.sh

The script is the project. Everything else is a licence and a short README. There is no package file, no configuration file, no service unit, no systemd documentation, no example and no test directory.

That shape tells you how the project expects to be used: as a thing you run once against a host you own, not as a library you depend on. It also means every question about behaviour has to be answered by reading the script, because nothing else in the repository holds the answer.

wget through a short link, then bash it immediately

The installation section is one line and one instruction, which is to run the script and follow the assistant:

```plain text wget https://git.io/wireguard -O wireguard-install.sh && bash wireguard-install.sh ```

Two details are worth pulling apart. The address is a shortened link, so the host you actually download from is not visible in the command, and the fetch and the execution happen in one step joined by &&. Nothing is verified between them.

The -O flag is what saves you here. Because the download lands in a file named wireguard-install.sh, you can run the wget half on its own, open the result, and only then run the bash half. The cost of that pause is one command, and the README does not mention it.

One entry point for install, user management and removal

The README says that once the script ends you can run it again to add more users, remove some of them, or completely uninstall WireGuard. So the same file is the installer, the user administration tool and the uninstaller, distinguished only by what you answer at the prompts.

Nothing in the README describes those prompts. How a new user is named, whether its keys or its config file are shown before they leave the terminal, whether an existing user can be listed or only added and removed: none of that is written down anywhere in the repository.

There is also no documented non-interactive mode. No flags, no environment variables and no config file appear in the README, which means adding a user in an automated pipeline is not something this repository offers a path to, and every run of the script expects a human at the keyboard.

Six distributions are named and no version of any of them

The description promises support for Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS and Fedora. That covers the Debian family twice over and the Red Hat family three times, which is the main reason to reach for this script instead of a distribution package.

What the README does not give is a version floor or ceiling for any of the six. No Ubuntu release, no Debian release, no Fedora release appears in the text, so a reader on a current point release has no way to tell from the documentation whether the script's assumptions still hold on that host.

The claim to weigh, then, is the broad one: designed to be as unobtrusive and universal as possible, and fast enough to set up a server in no more than a minute. Both are the project's own description of itself, with no test matrix, no issue template and no changelog in the repository to back them up.

The uninstall promise is also the audit you do not get

A script that can uninstall WireGuard also implies it installed something. The README does not enumerate a single thing: no packages installed, no kernel module mentioned, no sysctl setting, no firewall or NAT rule, no service name, no listening port.

On a host you built for this purpose that silence costs little, since you can throw the machine away. On a host that already runs something, it costs a lot. Nothing tells you which files the script wrote, which configuration it appended to, or what it would remove on a second run.

The uninstall path is the one to read before you trust the install path, and the only place to read it is wireguard-install.sh itself. Reading it is cheap: the install command already puts the file on your disk, and the repository never changes the file's name between runs.

The VPS recommendation is an affiliate link with a price on it

For readers without a server, the README suggests getting a VPS from AlphaVPS for 2 EUR or 2 USD per month. Both the euro and dollar figures point at the same host through an affiliate URL carrying an aff=474 parameter and a pid=457 product identifier, so the recommendation pays whoever left the link, and the price is stated as part of the pitch rather than measured.

That is worth knowing before the question of which VPS to choose. The repository gives no criteria at all: no region advice, no bandwidth or disk guidance, no comparison, no note about what a WireGuard server actually needs from a host.

It also means the cheapest documented path to running this script runs through a third party's checkout. If the point is a private tunnel for one laptop, that hop is an extra dependency for something the tunnel was meant to reduce.

Donations sit in the same README, and there is no version history

The last section asks for donations through a PayPal hosted button and through a cryptocurrency address published as a raw pastebin link, and it names no person, company or fund as the recipient. Nothing in the repository says what the money is spent on.

Maintenance information is thin in the same way. The last push was on 2026-09-16, the repository has no releases, and there is no changelog, no contribution guide and no stated support channel. So there is no way to tell from the project which version of the script you ran, and no way to ask what changed between two runs.

The practical consequence sits in the install line itself: wget fetches whatever the short link serves at the moment you run it. Because -O keeps the file, you can pin your own copy by diffing what you saved against what a later run downloads, which is the only version tracking this project offers.

Editorial conclusion

Use this script when you want a WireGuard road warrior server on a Linux host in one interactive pass and you accept that the README will not tell you what changed. Do not use it as a reference for how WireGuard is configured, since the repository documents no config file, no port choice and no client instructions, and do not paste it into a host you cannot rebuild. Two checks come before the run: read the saved wireguard-install.sh after wget finishes, because the URL is a short link that resolves to whatever is served today, and keep that file, since nothing in the install command pins a version.

Frequently asked questions

Official sources

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