Nyr/wireguard-install: a one-script WireGuard server for Ubuntu, Debian and RHEL-family hosts

The problem it solves: a WireGuard server without hand-written config

WireGuard itself is a kernel interface plus a userspace tool. Getting a road warrior server working means installing the packages, generating a server key pair, picking an address range, writing an interface config, enabling IP forwarding, adding NAT rules, and then repeating key generation and config writing for every device you want to connect. That is a page of shell and a set of decisions that are easy to get subtly wrong. The README describes the goal plainly: the script "will let you set up your own VPN server in no more than a minute, even if you haven't used WireGuard before." The audience is someone with a VPS and root access who wants remote access to a private network or a personal exit point, and who does not want to maintain the config by hand. The README also addresses the case where the reader has no server yet, pointing at a VPS provider with a listed starting price. The project is a shell script, not a daemon and not a service. It runs, it changes the system, and it exits.

What the script actually does between install and client config

The repository has three top-level entries: LICENSE.txt, README.md and wireguard-install.sh. Everything lives in that one script. Based on the README, the flow is: detect the distribution, install the WireGuard packages, create the server interface and its key material, then present an assistant that adds users. Each added user gets a key pair and a client configuration file the script writes to disk for you to transfer. The README states that running the script again lets you "add more users, remove some of them or even completely uninstall WireGuard," which means the script is re-entrant and uses its own state on the server rather than a database. That is the whole architecture. There is no API, no web panel, no agent on the client. The script targets Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS and Fedora, so the package installation branches by family: apt on the Debian side, dnf or yum on the RHEL side. The script is the unit of deployment and the unit of administration.

Installing it and adding a first client

The README gives one command. It downloads the script from a short URL and pipes it to bash, so read the file before you run it if you care what lands on the host.

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

Run it as root on a supported distribution. The assistant prompts for the settings it needs, installs the packages, and brings up the server interface. When it finishes you have a working server and no clients.

Run the same file again to add a user. The README says the script can be re-run for add, remove and uninstall, and that the assistant drives the choice.

bash wireguard-install.sh

What you should see is a menu rather than a fresh install, plus a generated client configuration for the user you create. That file is what you load into a WireGuard client on your laptop or phone. The script writes it on the server; moving it to the device is your job, and the README does not describe a transfer mechanism. The same re-run path is how you remove a user or tear WireGuard down completely.

Where this script stops being the right tool

The script is a server installer, and the repository contains no client. If you arrived looking for a Windows, macOS, iOS or Android client, wireguard-install.sh will not give you one; it configures the Linux side and hands you a config file that some other WireGuard client must consume. The second limit is administration. Adding and removing users means running an interactive script on the server. There is no expiry, no per-user bandwidth accounting, no revocation list you can query, and no audit log beyond whatever the shell and the system journal keep. For a handful of personal devices that is fine. For a team where people join and leave, the process is manual and depends on someone having SSH access. Third, the script makes system-level changes: package installation, interface configuration, forwarding and NAT. On a host that already runs other network services, or inside a container where the kernel interface is not available, those changes may conflict or fail, and the README does not document a rollback beyond the uninstall option in the assistant. Finally, the install command fetches from a URL shortener, so the bytes you execute are whatever that redirect currently serves; the README does not pin a commit or publish a checksum.

How it differs from a full WireGuard management panel

The obvious alternative is a web-based WireGuard management UI, typically deployed with Docker, that keeps server and peer state in a database and exposes an HTTP interface for creating clients, downloading configs and sometimes showing handshake status. The difference is where the state lives. wireguard-install.sh keeps state in the WireGuard configuration on the host and in files it generated, and you change it by running the script in a terminal. A panel keeps state in its own store, serves configs over HTTP, and lets someone without SSH create a peer. That convenience costs a running web service, a database or file store, an exposed port and its own upgrade path. If your requirement is a small number of devices and you are comfortable on the command line, the script has fewer moving parts. If you need self-service onboarding or an inventory of peers, the panel is the better fit and the script is the wrong layer. A third option is doing it by hand with wg and wg-quick; the script is essentially that work, packaged and made repeatable across six distributions.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-16, so the script is being touched, but there are no releases to pin to. That matters for upgrades: with no tags, the practical way to track changes is to watch commits on master and diff wireguard-install.sh before re-running it on a production host. Because the script is re-entrant and used for administration, an upgrade is not a separate operation from routine use. The file you download tomorrow is the file that manages your existing users. There is no version handshake between the script and the configuration it previously wrote, and the README does not describe a migration path or a compatibility guarantee across revisions. The licence is MIT, declared in LICENSE.txt, which permits use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and imposes no copyleft obligation on your own configuration or on the clients you connect. It says nothing about the WireGuard packages the script installs, which carry their own licences, and nothing about the terms of any VPS provider you use. Treat the MIT grant as covering this script only.

Editorial conclusion

Adopt it when you want a WireGuard server on one of the six supported distributions and you are content to manage users by re-running the script. Skip it if you need a client for Windows, macOS, iOS or Android, since the repository ships only wireguard-install.sh, or if you want central user management, expiry dates or an audit trail. Before you commit, open the script and read the Interface and AllowedIPs values it writes, then confirm the client config it produces matches the subnet you actually route.

Frequently asked questions

Official sources

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