One curl command, three install routes, and a best-effort warning at the top

The first thing in the README is a warning about maintenance

Before anything else, at the very top of the file, there is a callout that says PiVPN is maintained on a best-effort basis, and it links two release tags, v4.6.1 and v4.6.0, where the announcement lives.

That placement is unusual and worth respecting. A project that opens on a caveat about its own upkeep is telling you to plan for slow answers rather than to expect a vendor response. The Feedback and Support section says the same thing in different words: PiVPN is purely community driven, it is maintained with volunteers' free time, and the objective is for it to work for as many people as possible. It does not take donations, so contributing code or leaving feedback is the stated way to give something back.

The repository itself is not archived, and the last push to the repository was on 2026-08-30, and the default branch is master. The three newest release tags are v4.11.1 from 2025-09-13, v4.11.0 from 2025-08-16 and v4.10.1 from 2025-08-14, so pushes and releases are running on different clocks.

Three install routes, and all of them pipe a script into bash

Method 1 is a single line:

curl -L https://install.pivpn.io | bash

Method 2 skips the redirect service and goes straight at the raw installer on the master branch:

curl https://raw.githubusercontent.com/pivpn/pivpn/master/auto_install/install.sh | bash

Method 3 clones the repository and runs the same script yourself:

git clone https://github.com/pivpn/pivpn.git
bash pivpn/auto_install/install.sh

All three end in the same place, and all three execute a script you have not read. Method 2 is not more auditable than Method 1 in practice, since it still pipes into bash; Method 3 is the only one where the file exists on disk before it runs. That matters on a machine that will hold a VPN key, and it is the reason the clone route is the sensible default for anyone who cares what they are about to run.

Afterwards, management is the pivpn command. The design goal is stated plainly: a one command installer followed by easy management, so that a home VPN is as cheap as possible without the owner being a technical wizard.

The test branch is one environment variable away

Development installs are a documented variation, not a hidden one. The script is served from a different host and gated on an environment variable:

curl -L https://test.pivpn.io | TESTING= bash

Setting TESTING to an empty value is enough to make the installer behave differently. The README explains that this is for installing from the Test or Development branch, so the variable is the switch between the stable and development lines rather than a configuration option you would tune.

Below that sits an escape hatch for anyone working on the code. The installer accepts --giturl and --gitbranch, so you can point it at a fork and a feature branch instead of master, and the README notes that without those flags it will always check out the master branch:

git clone https://github.com/userthatforked/pivpn.git
bash pivpn/auto_install/install.sh --giturl https://github.com/userthatforked/pivpn.git --gitbranch myfeaturebranch

The unattended setup path takes the same two values as configuration keys:

pivpnGitUrl="https://github.com/userthatforked/pivpn.git"
pivpnGitBranch="myfeaturebranch"

Three ways to run unreleased code, all documented, which is more transparency than most installers manage.

Pull requests target the test branch and want a specific shfmt run

The contribution rules are specific enough to be useful. A pull request goes towards the test branch rather than master, the description has to state the problem and the solution, and the relevant issue number should be included if there is one.

Formatting is pinned to two external references: the Angular commit message format for commit lines, and the Google shell style guide for the code itself. The README then suggests the exact formatter invocation, which is the one line a contributor needs:

shfmt -i 2 -ci -sr -w -bn

Those are the flags that matter: two space indentation, switch cases indented, redirect operators followed by a space, write in place, and binary next line.

Issue handling is handled just as explicitly. Search the existing issues first, open a new one from the template if nothing matches, fill in every requested field even when it feels irrelevant, and include a code sample or an executable test case where you can. The team warns it may close any discussion or issue without warning if the guidelines are not followed, which is the one edge of this policy worth knowing before you post a one line question.

UFW-by-default distributions are in scope, and unattended configs ship for both protocols

The scope statement is broader than Raspberry Pi. PiVPN is said to work on most Ubuntu and Debian based distributions, including the ones that use UFW by default instead of raw iptables, which is the detail that separates installers that work on a modern cloud image from installers that do not. This project names the UFW case explicitly.

The second supported host is a cloud provider VPS running Ubuntu or Debian. The stated reason is about who sees your traffic: with the VPN on a server elsewhere, your home ISP only sees encrypted traffic leaving for the provider. The primary recommended host is still the latest RaspberryPi OS Lite image on a Pi at home, so the design centres on the small box you own.

For unattended installs the repository ships two example configurations under examples/, one per protocol: `examples/unattended_openvpn_example.conf` and `examples/unattended_wireguard_example.conf`.

Two protocols, two example files, and a script that can take its git coordinates from configuration rather than flags. That is the whole delivery mechanism, which is the point: there is no daemon to build and no package to install.

Support runs through Discussions first, and IRC and Matrix are the back channels

The support policy has an order to it. The preferred contact method is the GitHub Discussions page, and the general guidelines ask you to read the pinned posts there before opening anything. Searching existing issues is requested before opening a new one, with filters, because the volume of support traffic is what the volunteer policy implies.

Behind Discussions there are three named channels: the #pivpn channel on the libera.chat IRC network, #pivpn:matrix.org on Matrix, and the r/pivpn subreddit. Feature requests have their own Discussions category rather than going into the tracker.

Contributing back is framed just as concretely. The project does not take donations and instead points at three things: check the open issues and discussions, work on the documentation at the separate pivpn/docs repository, and improve the website. Documentation is described as never good enough, with typos and unclear English named as the gaps.

For an operator this all adds up to one practical point. If something breaks on a Pi in a cupboard and the Discussions page has no answer, there is no paid path to escalate to, so the hardening decisions you make yourself are the ones you will live with.

Shell scripts and a .releaserc, so the release train is automated

The repository is small and shaped around automation. The top level holds .github/, .releaserc, .travis.yml, CHANGELOG.md, CODE_OF_CONDUCT.md and LICENSE alongside the directories that matter: auto_install/ for the installer, scripts/ for everything else, examples/ for the unattended configs, files/, and ciscripts/ for CI scripts. The primary language is Shell, and the licence is MIT.

The presence of .releaserc and a semantic-release badge in the header says the tags are cut by tooling rather than by hand, which lines up with the semantic version numbers in the release history and with the CHANGELOG.md sitting at the root. Combined with the pull request rule that merges go to the test branch, the release picture is: development lands on test, master carries what has been judged ready, and the tag is produced from that.

The honest caveat is the one at the top of the file. Every part of that pipeline depends on volunteers, the project says so itself, and the last tag is from September 2025 while the repository's last push was on 2026-08-30. The automation is in place; the people deciding what ships are not on a schedule.

Editorial conclusion

Take PiVPN when you have a spare Raspberry Pi or a cheap VPS, you want WireGuard or OpenVPN with hardened defaults rather than a hand assembled configuration, and you are willing to administer the box yourself with the pivpn command afterwards. Leave it if you need mesh networking or a hosted service, because what PiVPN sets up is one server on one host. Verify four things. Read the warning at the top of the README and the release announcements it links, because the project describes itself as maintained on a best-effort basis by volunteers. Check that your distribution is one of the Ubuntu and Debian derivatives it claims, including those defaulting to UFW rather than raw iptables. Choose the install route deliberately, because all three pipe a remote script into bash and only the clone route lets you read it before it runs. And if you intend to send code, aim the pull request at the test branch and format it with shfmt -i 2 -ci -sr -w -bn.

Frequently asked questions

Official sources

1. License: MIT
2. pivpn/pivpn on GitHub
3. Project website
4. README
5. Releases