Self-hosted service
bivlked/amneziawg-installer avatar
bivlked/amneziawg-installer

amneziawg-installer: a shell installer that puts AmneziaWG on a bare Ubuntu or Debian VPS

One-command AmneziaWG 2.0 / 3.x installer for a self-hosted VPN server on Ubuntu and Debian: DPI bypass, traffic obfuscation, split tunneling, auto-hardening, client management. Includes a VPN cascade guide.

1,261 stars99 forksShellMIT

At a glance

What is it?
This Bash project turns a clean Ubuntu 24.04/26.04 or Debian 13 host into a self-hosted AmneziaWG server with one command, producing client QR codes and vpn:// links. The trade-off is that it takes over the machine: it removes packages, disables IPv6 by default, and only partly rolls back.
Who is it for?
Adopt it if you have a dedicated Ubuntu 24.04, Debian 13 or Ubuntu 26.04 VPS, you are comfortable with the script taking root, and you want AmneziaWG rather than WireGuard. Do not adopt it on a shared host, a router, a machine that also runs other services, or any host where you cannot afford to lose unattended-upgrades and cloud-init.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Shell, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The censorship problem it is built around

Plain WireGuard is easy to detect. Its handshake has a recognisable shape, and DPI middleboxes in several countries use that shape to block or throttle the protocol. AmneziaWG is a fork that keeps WireGuard's key exchange and performance model but adds obfuscation parameters so the traffic does not look like WireGuard on the wire. The installer exists because setting that up by hand means building a kernel module through DKMS, writing sysctl files, configuring UFW and Fail2Ban, and then generating client configs that the Amnezia client can import. That is an afternoon of work for someone who already knows Linux, and a wall for someone who does not.

The README states the target plainly: any VPS for a few dollars, no Linux knowledge required. The audience is a person who rents a small Ubuntu or Debian box and wants a working VPN endpoint, including on mobile networks where DPI is active. The project also lists ARM64 and ARMv7 among supported architectures, which covers Raspberry Pi boards and Ampere-based cloud instances. It is not aimed at routers, shared hosting, or anyone who wants a web panel to click through.

What the script actually does to the machine

The installer is a Bash script downloaded from the releases page. The README's transparency section lists its actions in order. It updates the system and installs dependencies including amneziawg-tools and qrencode. It adds the Amnezia PPA after checking the GPG key against a full fingerprint, then builds the AmneziaWG kernel module through DKMS. On kernels older than 6.7, which includes stock Debian 12, the documentation says it falls back to a verified 2.0 module built from source; for some ARM targets it uses prebuilt modules.

Networking changes are written as separate files under /etc/sysctl.d/: forwarding, socket buffers, BBR. IPv6 on the host is disabled by default, with --allow-ipv6 as the opt-out. Swap is sized against RAM. UFW is configured to deny inbound, rate-limit SSH, and open only the VPN's UDP port, and Fail2Ban is set up for SSH. Server files live in /root/awg/ and /etc/amnezia/amneziawg/ with 600/700 permissions, the tunnel runs as the awg-quick@awg0 service, and a cron job removes expired clients. The release notes for v5.31.0 say the default install no longer lets IPv6 traffic escape around the tunnel, which tells you the earlier default was leaky.

One detail worth pausing on: the script removes unattended-upgrades. The README says so directly, and notes the consequence, that automatic security updates stop. That is a real behaviour change on a machine exposed to the internet, and it is not reversible through --uninstall.

Install commands and the flags that matter

The documented quick start is three commands:

wget -O install_amneziawg.sh https://github.com/bivlked/amneziawg-installer/releases/latest/download/install_amneziawg.sh chmod +x install_amneziawg.sh sudo bash ./install_amneziawg.sh

The README says this takes about 20 minutes and two reboots. For unattended runs there is a non-interactive mode:

sudo bash ./install_amneziawg.sh --yes --route-all

Two flags carry most of the practical weight. --mobile applies an obfuscation preset and switches the listening port to 443/udp in one step, which the README frames as the answer for mobile networks where DPI interferes. --allow-ipv6 keeps host IPv6 enabled instead of the default shutdown. Client management afterwards uses manage_amneziawg.sh, for example:

manage_amneziawg.sh add guest --expires=7d

That creates a time-limited client, and the cron job mentioned above is what later removes it. The v5.32.0 release notes add two capabilities to this surface: the machine-readable interface now reports client expiry, and client routes can be set at creation time, so split tunnelling can be decided when the client is made rather than edited afterwards. The README also points at --uninstall for rollback. Per the documentation, uninstall removes the module, configs, sysctl files, cron entries, the UFW rule for the VPN port, and the awg0 routing rule. It disables UFW and removes Fail2Ban only if the installer turned them on; if UFW was already active, the SSH rate-limit rule it added stays. It does not restore swap or the packages it deleted.

Protocol generation is not the same as config generation

The facts block in the README draws a distinction that is easy to miss. The configuration profile is AmneziaWG 2.0, and the generated client configs stay 2.0 even when the kernel module is a 3.x build. So a user who installs on a modern kernel and sees 3.x in the module version should not assume the emitted configs use 3.x features. The project describes the module line and the config line as separate things, and v5.32.0's release note about an installation recording its protocol generation suggests this is now tracked rather than inferred.

That is a deliberate conservative choice, and it has a cost. It means the installer's output is interoperable with clients that only speak 2.0, at the price of not exposing whatever 3.x adds. For someone whose goal is a working tunnel that survives DPI, that trade is probably right. For someone specifically chasing a 3.x capability, this installer is not the route to it, and the README's own section on AmneziaWG 3.x is where the boundary is documented.

Where it goes wrong, and when it is the wrong tool

The installer assumes it owns the host. It removes cloud-init if cloud-init is not managing the network, it removes unattended-upgrades, it rewrites sysctl state, and it resizes swap. On a fresh throwaway VPS that is fine. On a box that runs anything else, it is a problem, and the README does not pretend otherwise: it says the script is for a clean Ubuntu or Debian VPS, not a router and not shared hosting.

The rollback is the sharper limitation. --uninstall is documented as partial. Swap is not restored, deleted packages are not reinstalled, and a pre-existing UFW configuration keeps the SSH rate-limit rule the installer added. Anyone treating the install as reversible should read that list before starting, not after. There is also a platform ceiling: the README marks Ubuntu 25.10 and Debian 12 as not for new servers because they are outside normal vendor support, and the kernel-module path differs on older kernels, so the experience is not uniform across the supported matrix.

Integrity checking is the last friction point. The script is fetched over HTTPS from a pinned tag, helper scripts (awg_common, manage) are verified against pinned SHA256 hashes, and releases carry a detached minisign signature. That is a reasonable chain, but it puts the verification step on the user. Downloading and running the script without checking the signature means trusting the release page, which is exactly the trust the signatures exist to remove.

The alternative: plain WireGuard, configured by hand or by a panel

The most direct alternative is upstream WireGuard installed from the distribution repositories and configured manually. The difference is not cosmetic. WireGuard needs no DKMS build because the module ships in modern kernels, so there is no PPA, no compilation step, and no kernel-version fallback logic. It also has no obfuscation parameters, which is the whole point of AmneziaWG and the reason a WireGuard endpoint can be fingerprinted and blocked where AmneziaWG is not. Choosing WireGuard means accepting that detectability in exchange for a simpler, more portable, more easily reversible setup.

The other alternative is a management panel that wraps WireGuard or AmneziaWG with a web interface. The README positions this project against that category, framing the choice as CLI versus panel. A panel gives you a browser UI for adding clients and is easier for a non-technical operator to hand over. It also adds a web service listening on the host, its own dependency tree, and an update path you do not control. This installer produces no web panel and no Docker layer, which keeps the attack surface to the kernel module, the tunnel service, SSH, and Fail2Ban. If you want a UI, this is not it.

Maintenance, licence, and what to check before you commit

The project is MIT licensed, which permits commercial and private use, modification, and redistribution with the licence text retained. That covers the installer script itself. It does not automatically cover what the script installs: the AmneziaWG kernel module and the amneziawg-tools package come from the Amnezia PPA and carry their own licensing, and the operating system packages pulled in during the run are governed by their own terms. Read those separately rather than assuming the MIT badge on this repository extends to the whole stack. Nothing here is legal advice.

Maintenance cost is mostly the kernel module. DKMS rebuilds the AmneziaWG module on kernel upgrades, so a routine apt upgrade that pulls a new kernel triggers a build. When that build fails, the tunnel does not come back after reboot, and the failure surfaces as a missing interface rather than an obvious error. The project's choice to remove unattended-upgrades interacts with this: you are now the one applying kernel updates, which means you are also the one who sees the rebuild fail. That is a defensible design for a VPN-only host and a poor one for a machine you do not log into regularly.

The installer is at 5.32.0 with releases landing through September 2026, so the project is actively maintained and the CLI surface is still moving: expiry reporting and creation-time routes both arrived in v5.32.0. Before running it, verify the downloaded script's SHA256 and minisign signature against the release page, read the package removal list in ADVANCED.md, and decide the IPv6 question up front, since --allow-ipv6 has to be passed at install time rather than corrected later.

Editorial conclusion

Adopt it if you have a dedicated Ubuntu 24.04, Debian 13 or Ubuntu 26.04 VPS, you are comfortable with the script taking root, and you want AmneziaWG rather than WireGuard. Do not adopt it on a shared host, a router, a machine that also runs other services, or any host where you cannot afford to lose unattended-upgrades and cloud-init. Before running it, read ADVANCED.md for the full package removal list, decide whether you need --allow-ipv6 or --mobile, and check the script's SHA256 and minisign signature against the release page.

Official sources

  1. bivlked/amneziawg-installer on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community notes

Community notes