openvpn-install: a one-line OpenVPN install script with no client half

The whole install is one wget line piped into bash

The command the project gives you is a single line, and it is worth reading before you paste it:

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

The first half downloads a file called openvpn-install.sh into your current directory, the second half hands that file to bash. Everything the README says about running it amounts to two sentences: run the script and follow the assistant, and you will have your own VPN server in no more than a minute even if you have never used OpenVPN before. So the flow is an interactive assistant, not a set of documented options. No flag is specified in the README, no dry run, no way to see what the script will touch before it touches it. And because the URL is a shortened link, the host serving those bytes is not visible in the command itself. The repository does keep a file with the same name, openvpn-install.sh, on the default branch master, and that is the copy to read first if you want to know what the line is about to execute.

Six distributions named, no package named

Six distributions appear in the project's one line description: Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS and Fedora. That is the whole support statement. No package name, no service name, no configuration path, no prerequisite list and no kernel requirement appear in the README, so how the script bridges the gap between a Debian release and a Fedora release is something you learn by reading openvpn-install.sh rather than by reading documentation. Nothing claims support for anything outside those six names, which makes the intended reader narrow: an administrator who already owns one of those machines and has never configured OpenVPN before, who wants a per-user tunnel into it rather than a link between two networks. The machine is a precondition, and the README answers that with its only commercial detail, a VPS from AlphaVPS starting at 2 EUR or 2 USD per month, plus a PayPal button and a cryptocurrency address for anyone who wants to fund the work. It says nothing about backups, bandwidth, or what to do after the box is rebuilt.

Rerunning the script is the entire admin interface

The README puts the lifecycle in one sentence: once it ends, you can run it again to add more users, remove some of them or even completely uninstall OpenVPN. Add users, remove users, remove the server. There is no fourth choice and no second tool, and that shape decides what you can automate. No non-interactive flags are documented, so Ansible, a config management run, or a pipeline that has to provision a hundred accounts has nothing to call. The repository also documents no way to rotate one person's profile, set an expiry on it, or confine a user to a subset of subnets. Nor does it say what a rerun does to the profiles already handed out, so an operator who adds a second user has to go and look at the server to learn what the first run left behind. Uninstall sits in the same sentence as everything else, which means there is no documented way back from a run that stopped halfway.

The client half is missing: no app, no profile, no download

Everything this project covers happens on the server. The README never names a client application, never links a download for one, never says which file a user is supposed to import, and never says where that file is written. Phones and desktops are not mentioned at all. OpenVPN on Windows, on macOS or on Android is a client install that comes from somewhere else entirely, and this repository has nothing to say about it. A finished server run still leaves two questions open: where the per-user profile lands, and how it reaches the machine that needs it. That profile is the credential, so the second question decides whether a phone ends up holding something you cannot revoke without going back to the server. The description calls this a road warrior setup, which is precisely the arrangement where the missing half bites hardest: many people, each with their own account, each needing a file nobody told them how to get.

Three files, no releases, no changelog

The repository has three top level entries and nothing else: LICENSE.txt, README.md and openvpn-install.sh, written in Shell, under the MIT license, with master as the default branch. There are no GitHub releases, so there is no version to pin, no release note to read, and no upgrade path from one version to the next. The last push was on 2026-09-22, recent enough that the script does change under you, which leaves the commit log of a single file as the whole history available to a reader. A question like what differs between the run you did last month and the run you are about to do gets answered by reading a diff. MIT is the permissive end of the licence menu and lets you vendor the script into your own provisioning, and it carries no warranty at all, which matters more than usual for something whose behaviour is defined by its source instead of by a documented interface.

Ciphers, ports and certificates appear nowhere

The values that decide how a tunnel behaves are not written down anywhere. The data channel cipher, compression, the listening port, certificate lifetimes, whether password authentication stays enabled, where the log file goes, what happens to IPv6 traffic: none of these appear in the README. The consequence is that this project cannot be reviewed from what it publishes. You can read openvpn-install.sh and see what it decides to write, and after a run you can read what it wrote, but a decision to put this on a network you care about rests on those two readings. Nobody can hand you the cipher from the documentation here, because the documentation does not carry it, and the same goes for the port and the certificate lifetime. Treat the server's own files as the source of truth, not the README.

wireguard-install sits one line above it, on a different protocol

The first line of the README points at Nyr/wireguard-install, the same author's other installer, and marks it as the new one. The two are not the same thing underneath. OpenVPN clients authenticate with a client certificate and a client key, which is the reason per-user provisioning exists in this script at all: every account added is another set of credentials to issue, store and revoke. WireGuard has no certificate authority inside the tunnel. Each peer holds a private key, the server holds the matching public key, and a peer's configuration is a short INI style file. If certificate handling is what turns you away from OpenVPN, that difference is the one that matters. If what turns you away is that the client step is undocumented, switching protocol changes nothing, because this repository documents the client step for neither of them.

Editorial conclusion

Adopt openvpn-install if you already have one Linux box on one of the six distributions it names and want per-user OpenVPN access without writing a server configuration by hand. Skip it if you need clients documented, unattended provisioning, or a version you can pin, because the repository holds three files, no releases and no client instructions. Before the first run, read openvpn-install.sh on master and compare it with the file bash is about to download, then read the configuration the run left on the server: the cipher, the port and the certificate lifetimes exist nowhere in the documentation.

Frequently asked questions

Official sources

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