angristan/wireguard-install: a bash script that turns a Linux server into a WireGuard VPN endpoint

What the script actually replaces

Setting up WireGuard by hand on a server means generating a server key pair, choosing a tunnel subnet, writing an interface config, enabling IP forwarding, adding NAT rules, opening the UDP port in the firewall, and then repeating the key generation for every client. Each of those steps is short, and each of them is a place to make a mistake that produces a tunnel which connects but does not route. The README describes the project as a bash script that aims to set up a WireGuard VPN on a Linux server as easily as possible, and that is the whole scope: it automates the server side of a point-to-point VPN used as an internet gateway.

The intended user is someone with a Linux box and root access who wants their client traffic to leave through that box's IP. The README is explicit about the model: the client forwards all its traffic through an encrypted tunnel to the server, and the server applies NAT so the client appears to browse with the server's IP. That is a full-tunnel gateway, not a site-to-site mesh and not a way to reach services on a private LAN behind the server. If you want the second thing, the script's NAT default is the wrong starting point and you will be editing the generated configuration afterwards.

It is also deliberately a server-side tool. The client config file it produces is a text file you still have to move to a phone or laptop and import into a WireGuard client. The README does not describe a client installer.

How the installer works: one script, host-level changes

The repository layout is unusually flat. The top level contains .github/, LICENSE, README.md and wireguard-install.sh. There is no library directory, no configuration template tree and no packaging metadata. Everything the project does lives in that one script, which means the way to understand its behaviour is to read it, not to read documentation about it.

According to the README, running the script installs WireGuard (kernel module and tools) on the server, configures it, creates a systemd service and a client configuration file. Those four verbs describe the data flow.

Two consequences follow from that design. First, the script is stateful in the ordinary filesystem sense: it configures WireGuard on the host and creates a systemd service, so the host is the source of truth, not the repository. Second, re-running the script is the management interface. The README says to run the script again to add or remove clients, which means client lifecycle operations are interactive prompts against existing state rather than declarative edits to a file you keep in version control. For a single server this is convenient. For a fleet it is not a workflow, and nothing in the README suggests the project aims to become one.

Installing it and adding a first client

The README gives a three-command install: download the script, make it executable, run it. It is meant to be run on the server, as root, on one of the supported distributions (AlmaLinux 8 and later, Alpine, Arch, CentOS Stream 8 and later, Debian 10 and later, Fedora 32 and later, Oracle Linux, Rocky Linux 8 and later, Ubuntu 18.04 and later).

curl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh
chmod +x wireguard-install.sh
./wireguard-install.sh

After that, the script asks questions and takes care of the rest: it installs the WireGuard kernel module and tools, configures the interface, creates a systemd service and writes a client configuration file. Expect to be prompted for the values that define the tunnel. The README does not enumerate every prompt, so read the script if you need to know the exact set before you start answering.

The client side is a separate step. Take the generated client configuration file, install the WireGuard client for your platform, and import the file. The README does not document a transfer mechanism, so how the file reaches the device is your problem: scp, a password manager attachment, or a QR code from a tool you install yourself.

Adding a second client means running the same script again.

./wireguard-install.sh

The README states that running the script again lets you add or remove clients. That is the entire client management surface. There is no separate command with flags, and the README does not document a non-interactive mode, so anything you want to automate around this script has to deal with its prompts.

Where the script is the wrong tool

The clearest limitation is the one the README states by omission: there is no documented rollback. The script writes system configuration, enables forwarding, adds NAT rules and creates a systemd service, but the README does not describe an uninstall path, a way to revert the network changes, or a dry-run mode that shows what would be modified. On a server you also use for other things, that asymmetry matters more than the install convenience. You are trusting a script you have not audited to leave your networking in a working state, and the project's own guidance is to check the issues and discussions for ongoing development and bugs.

The second limitation is the topology. NAT-style full-tunnel VPN is what this installs, and the README says so plainly. If your goal is to route between two private networks, to give clients stable addresses that other clients can reach, or to expose services on the server's LAN, you are working against the default rather than with it. WireGuard supports those topologies, but the README describes only the NAT gateway model.

The third is operational scale. Every client operation is an interactive run on the server. The README describes no inventory or other management features beyond adding and removing clients. The README's answer to operational questions is the issues and discussions pages, which is a reasonable answer for a script and a poor one for a service with dozens of users.

Finally, the script targets servers. If what you actually need is a client on a laptop or phone, this is not the project. The README's supported platform list is a list of Linux server distributions, and nothing in it addresses Windows, macOS, iOS or Android.

The honest alternative: openvpn-install from the same author

The README itself points to openvpn-install, by the same author, for environments where WireGuard does not fit. The difference is not cosmetic. OpenVPN runs in userspace over TLS and can use TCP, including port 443, which makes it far more likely to pass through restrictive networks and captive portals that block unfamiliar UDP traffic. WireGuard is a kernel module speaking its own UDP protocol, which is why the installer's job includes loading a kernel module and why the README lists kernel-module installation as part of what the script does.

That has a practical consequence for the choice. If your users are behind networks that only permit TCP 443, an OpenVPN endpoint is the safer bet and the sibling project is the direct answer. If your users are on ordinary networks and you want the smaller, faster tunnel and a simpler configuration file, WireGuard is the better fit and this script is the shortest path to it on a supported Linux host.

Maintenance, licence and the cost of staying current

The last push to the repository was on 2026-05-02. The repository is not archived. The project is a single shell script, so the upgrade path is to re-download wireguard-install.sh and run it again, or to pull the file from the repository and diff it against your copy before running. The README does not document a versioning scheme, and the repository has no published releases, so there is no changelog to read before you upgrade. That is the real maintenance cost here: you cannot read a release note to find out what changed, you have to read the diff.

Contributions are gated by shellcheck and shfmt, run on each commit and pull request through GitHub Actions, with the configuration in .github/workflows/lint.yml. That matters for anyone who wants to patch the script for their own distribution or topology: the style rules are enforced, so a patch that passes the lint workflow is more likely to be accepted. The README asks contributors to open an issue before submitting a pull request, particularly for large changes.

The project is under the MIT Licence. In practical terms that is a permissive licence that allows modification and redistribution provided the copyright notice and permission notice are preserved, but the LICENSE file is the authoritative text and nothing here is legal advice. If you fork the script for internal use, keep the licence file with it. The README also contains referral links to cloud providers, which is worth knowing when you read the provider recommendations: they are the author's suggestions, not neutral comparisons.

Editorial conclusion

Adopt it if you want a NAT-style WireGuard endpoint on one of the supported distributions and you are comfortable with a script that edits the host network configuration directly. Do not adopt it if you need multi-server management, a web UI, or a client-side installer: the repository ships one shell script and a README, and the README lists only Linux server distributions as supported. Before running it, confirm your distribution is on the supported list, check that the host has a public IPv4 or IPv6 address, and read wireguard-install.sh to see exactly which files it writes and which services it restarts on your machine.

Frequently asked questions

Official sources

1. angristan/wireguard-install on GitHub
2. Issues
3. License: MIT
4. Project website
5. README