AmneziaWG 3.0 on your own server: which line you get and whether to upgrade
Short answer: the installer picks the protocol line for your kernel and architecture, and you enable nothing by hand. On x86 with a recent kernel the third line already arrives on its own; on Debian 12 and on part of the ARM range the proven second line stays. Client configs work either way, and you do not need to reissue them.
See what is running on your server
Two commands over SSH. Both are read-only and change nothing.
What the server is running:
cat /sys/module/amneziawg/version # version of the loaded module awg --version # version of the userspace tools
The first command reads the version attribute of the module running in the kernel right now, not of a file on disk. That attribute is declared in both lines. If the module is not loaded there will be no output - then modinfo amneziawg | grep ^version shows what sits on disk.
Why not modinfo by default: it reads metadata from whichever file is selected on disk. If two module trees with the same name ended up on the host, which happens on ARM, it will name the wrong one. Since v5.25.0 both manage check and manage diagnose ask the loaded module first.
⚠️ The apt package version does not answer this question, and it is easy to be misled here. dpkg -l amneziawg-dkms prints a string starting with 1.0.0 - that is the packaging version, not the protocol one, and people who see it usually conclude they are on the first version. Only the commit hash at the end identifies the line. Rather than guessing from apt, ask the module itself with the command above.
Which line your server gets
One rule, applied automatically at install time.
| Your server | Where the module comes from | Line |
|---|---|---|
| x86_64, kernel 6.7 or newer | Amnezia team's PPA | third |
| Kernel older than 6.7 (Debian 12 with 6.1), and on ARM no prebuilt matched | pinned module built from source, tag v1.0.20260725 | second |
| ARM64 or armhf, a prebuilt package matches your kernel | our prebuilt package | second |
| ARM64 or armhf, no prebuilt match, kernel 6.7 or newer | Amnezia team's PPA | third |
The order on ARM matters and often surprises people: the prebuilt package is tried before the PPA module is installed, and if it fits, the PPA module is not installed at all - the installer keeps it under apt-mark hold. The PPA repository itself is already configured by then, and the userspace tools come from it. So on ARM with a recent kernel you may well get the second line: not by mistake, but because a match was found. Prebuilts are built for Raspberry Pi 3, 4 and 5, Ubuntu 24.04 and 25.10 ARM64, and Debian 12 and 13 ARM64, and all of them are pinned to the same v1.0.20260725 tag as the source build. That is our choice rather than a limitation: the third line has been building on older kernels since late July. The pin exists for predictability - an ARM owner gets the same proven module as everyone else instead of a random line from a moving branch.
On kernels older than 6.7 the second line is chosen deliberately. The third one did fail to build there for the first day after release, upstream fixed that on 31 July 2026, and it builds today. The threshold stays because the third line has the least mileage precisely on older kernels, while the pinned second line is verified against an immutable commit. It will be lifted after a separate validation, not because the build passes again.
Do you need to upgrade
Three cases. The arrival of the third line requires no manual switch in any of them.
x86 with a recent kernel
Once the installer has chosen the PPA path, later releases of that package arrive through a normal apt upgrade: nothing to enable, and client configs are left alone. The reverse does not hold: apt upgrade on its own will not move a server off the pinned path - the package is held there, and the choice is only revisited when the installer runs again.
Debian 12, or ARM with a prebuilt
The module is pinned to the immutable tag v1.0.20260725, and new code does not reach it automatically. The installer keeps the PPA package amneziawg-dkms under apt-mark hold specifically so it cannot land beside the pinned or prebuilt module: otherwise the system would end up with two trees under one module name. The tunnel keeps working; updates simply do not arrive. One thing to keep in mind: after a kernel change the module has to appear for the new kernel. On the DKMS path that happens on its own, an apt hook and a boot-time service run the rebuild, and manage repair-module is only needed when that automation fails. On ARM with a prebuilt there is nothing to rebuild: run the installer again with --force and it picks a package for the new kernel or falls back to DKMS.
You want the third line on such a host
There is one supported path: get a kernel of 6.7 or newer (on Debian 12 that means a backports kernel) and reinstall. On ARM mind the order: if a prebuilt matches the new kernel, you will get the pinned second line again.
The current command set has no separate "upgrade the protocol" command: the module line is chosen during installation or reinstallation rather than switched on the fly.
🔴 One exception ARM owners should know about: the line can change by itself after a reboot. If the amneziawg-dkms package ends up alongside a prebuilt module, then once kernel headers appear DKMS builds, displaces the prebuilt file, and after a reboot that build is what loads - a different protocol line. The tunnel does not go down, and dpkg still reports the prebuilt package as installed. The installer prints a warning for this case: it gives exact commands for removing the DKMS package and putting it back under hold, while installing the module again and rebooting is described in words - stop after the removal and the new kernel can end up with no working module. Checking the version after a reboot is worth doing anyway: the answer to "what am I running" is not permanent.
What happens to client configs
Nothing. Configs you have already handed out keep working without a single edit, and there is no need to reissue them. The installer writes them in second-line format: junk packets Jc, Jmin, Jmax, padding S1-S4, ranged headers H1-H4, and signature packets I1-I5 when set. A third-line module serves those configs.
To leave no room for misreading: the installer selects a kernel-module line, while generated configs and vpn:// links stay in protocol version 2 - the link itself carries protocol_version set to 2. The project does not enable or configure third-line features.
Third-line features do not make it into generated configs yet, and that is not an oversight. They need client applications that understand them. A few third-party clients have already claimed the third line, but the applications most people actually use have not caught up: as of 17 August 2026 the latest release of the flagship Amnezia app predates 3.1. Turning such parameters on only on the server is not an option: some of them must match on both ends, and enabling such a parameter on the server alone would cut off every existing client at once.
What the third line adds
The short version, without byte-level detail. The full breakdown lives in the advanced docs.
| What was added | What it is for |
|---|---|
| Header encryption | Fields that stayed in the clear in the second line stop being a ready-made structure for an observer. WireGuard's own cryptography was left untouched. |
| Extra padding inside the encrypted part | Shifts the predictable packet-length alignment that was itself a tell. It does not have to match between sides. |
| Configurable timings | Rekey, handshake and keepalive intervals became configuration parameters instead of hard-coded protocol constants. They do not have to match between sides. |
All of these are optional and set separately. While none of them is set, a third-line engine puts exactly the same format on the wire as the second one - which is precisely why your current configs keep working. Our installer sets none of them.
Releases continue inside the third line. As of 17 August 2026 the PPA carried 3.1, which added two more parameters; a repository can lag behind a fresh upstream release, so we do not print a fixed number here. The check command above answers accurately on any given day.
FAQ
Which AmneziaWG version does the installer put on a server?
v1.0.20260725. On ARM the order differs: the installer first tries our prebuilt package, pinned to that same second line, and the kernel rule decides the outcome only when nothing matched. So on ARM the second line is possible even with a recent kernel.How do I check which AmneziaWG version runs on my server?
cat /sys/module/amneziawg/version - it reads the version attribute of the module loaded into the kernel, not of a file on disk. For the userspace tools, run awg --version. Do not use modinfo for this: it reads a file on disk, and if two module trees with the same name ended up on the host it may name the one that is not running.Do I need to upgrade AmneziaWG on my own server?
apt upgrade. On Debian 12 or on ARM with a matching prebuilt the module is pinned on purpose to an immutable tag, and a plain apt upgrade will not move it to the third line: the PPA package is held, and the choice is only revisited when the installer runs again. After a kernel change the module has to appear for the new kernel: on the DKMS path an apt hook and a boot-time service do that, while manage repair-module stays a manual recovery for when the automation fails. On ARM with a prebuilt there is nothing to rebuild, you run the installer again with --force.Will my existing client configs stop working?
vpn:// link shows this too: its protocol_version field is 2. There is no need to reissue clients. That is about the module line changing. Reissuing is needed in a different case: run the reinstall with obfuscation flags, that is --preset, --jc, --jmin, --jmax or --no-cps, and the installer regenerates the whole Jc, S, H and I1 set and warns you that the configs you handed out have to be replaced.What does the third AmneziaWG line add over the second?
Why do third-line features not show up in my configs?
Can the AmneziaWG version change by itself after a reboot?
amneziawg-dkms package ends up alongside a prebuilt module, then once kernel headers appear DKMS builds, displaces the prebuilt module file, and after a reboot that build is what loads - a different protocol line. The tunnel does not go down, and dpkg still reports the prebuilt package as installed. The installer prints a warning for this case: it gives exact commands for removing the DKMS package and putting it back under hold, while installing the module again and rebooting is described in words. Stop after the removal and the new kernel can end up with no working module, so checking the version after a reboot is worth it regardless.Why does Debian 12 get the second line instead of the third?
Where to look next
Parameter reference
What changes on the wire, which parameters were added and what has to match between server and client - see ADVANCED.en.md.
Install from scratch
A step-by-step guide for a clean VPS is in INSTALL_VPS.md. The installer picks the module line for you.
Managing clients
Adding, removing and reissuing clients after the install is covered on the client management page.