WireGuard peer management requires two changes: update the interface that is running now and keep the configuration used at its next start consistent. Add a device with its own key and address; revoke it by removing its public key from both places, then verify rejection rather than trusting a successful command.

Key Takeaways:

Keep a device-to-public-key inventory and an independent administration path.

File edits followed by reload suit peer changes within the existing routed subnet.

A reboot and a backup restore must not bring a revoked identity back.

What does WireGuard peer management cover?

This procedure targets Ubuntu 24.04 LTS, the distribution's WireGuard tools, and a native wg-quick@wg0 systemd unit. It follows the listed official documentation; no complete author end-to-end test was performed. The checks below describe expected behavior for you to verify, not observed test results. For the wider responsibility model, start with the self-hosting maintenance overview.

The example assumes an already working server at 10.77.0.1/24, an existing device at 10.77.0.2, and an unused new address 10.77.0.3. Substitute your actual, non-overlapping subnet. This is device lifecycle work, not a server installation or a panel tutorial. If the distinction between keys and peers is unfamiliar, review how WireGuard identifies both ends.［1］

Have sudo access, a verified provider console or SSH path outside this tunnel, a maintenance window, and a protected backup location. Pause any configuration generator for this interface through its documented management process. If a panel or another administrator owns the file, stop here and use that owner's workflow; two writers can undo each other's revocations.

Step 1: Reconcile the live and saved peer inventories

Run only selectors that avoid printing private keys:

sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 peers
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer

Compare public keys with the [Peer] entries in /etc/wireguard/wg0.conf using a private local editor. Record device owner, public key, assigned address, approval date, and whether access is active or revoked. Public keys are identifiers, but the inventory still describes private infrastructure; do not post it publicly. Never paste wg showconf, wg show ... dump, a complete configuration, or a QR code into a support ticket.［4］

Use a file-managed configuration for this guide: SaveConfig must be absent or false. With SaveConfig=true, shutdown saves live state over the file and can overwrite your edits. If it is enabled, first reconcile every intentional live change with the saved file, make a protected copy, then remove that setting in the file before any shutdown. Do not blindly run wg-quick save over an edited configuration.［3］

Make a uniquely named, root-only backup through the console, for example:

sudo install -d -m 700 /root/wg-peer-backups
sudo test ! -e /root/wg-peer-backups/wg0.before-peer-change.conf
sudo install -m 600 /etc/wireguard/wg0.conf /root/wg-peer-backups/wg0.before-peer-change.conf

Run these commands individually and stop if any fails; the example name must be changed for a later operation. Keep the revocation ledger separately from historical backups. A backup can correctly reproduce an old file and still restore access that should no longer exist.

Step 2: Add a device without taking another address

Generate the new device's key pair locally on that device, or through its trusted client's key-generation interface. For a Linux client, use a new private directory and do not overwrite an existing identity:

(
  set -eu
  umask 077
  mkdir wg-new-device
  cd wg-new-device
  wg genkey > private.key
  wg pubkey < private.key > public.key
)

Run the entire block together: its subshell stops at the first failure. If the directory already exists, choose an unused directory name; do not reuse it or delete an existing identity to make the command succeed. If key generation fails, do not distribute or configure any files from that attempt.

Send only public.key to the administrator through an authenticated channel. Keep the private key on the device; do not reuse the existing laptop's key. Check both the allocation inventory and the live allowed-ips listing before assigning 10.77.0.3/32. Duplicate or overlapping peer ranges can move traffic to the wrong device even when both configurations parse.［1］［4］

Append this peer to the existing server file with sudoedit; replace the uppercase placeholder with the complete new public key. Preserve the interface and all unrelated peers:

[Peer]
# new-device
PublicKey = NEW_DEVICE_PUBLIC_KEY
AllowedIPs = 10.77.0.3/32

On the new client, assign its own private key, Address = 10.77.0.3/32, the existing server public key and Endpoint, and only the intended destination ranges. Do not copy the server-side AllowedIPs into the client as if the roles were interchangeable. For a split tunnel to the server subnet, the client might use 10.77.0.0/24; for an existing full tunnel, preserve its established routing, DNS, IPv6, and failure policy. This guide does not widen them.［2］

Step 3: Apply and verify a WireGuard persistent peer

Save the reviewed file, keep it root-owned with mode 0600, and reload the active unit:

sudo systemctl reload wg-quick@wg0
sudo wg show wg0 peers
sudo wg show wg0 allowed-ips

Ubuntu documents reload for adding or removing peers without rebuilding existing tunnels. It updates WireGuard settings, not interface addresses, routes, firewall hooks, or DNS hooks. Our added /32 sits inside the server's existing connected /24; a new routed subnet needs its own reviewed routing change and possibly a maintenance restart. Do not treat reload as an all-purpose network reconfiguration.［2］

Initiate traffic from the new device to a permitted service on 10.77.0.1, then check that its handshake timestamp advances and the intended service responds. Repeat an application request from an unchanged device. A handshake proves cryptographic communication with a peer; it does not prove forwarding, name resolution, application permissions, or every protocol works.

If the new device never handshakes, compare its identity with the inventory and use the key-pair mismatch checks. If an existing device breaks, stop additions and examine the exact changed ranges. Remove only the erroneous new entry from the saved file, reload the active unit, and retest the existing device; do not replace the entire peer population.

Step 4: How do you make WireGuard revoke device access?

Identify the public key from the inventory, not from a recently seen roaming endpoint address. For confirmed compromise, remove that identity from the live interface immediately, before slower investigation:

sudo wg set wg0 peer REVOKED_DEVICE_PUBLIC_KEY remove

Replace the placeholder first. Delete the matching whole [Peer] section from the saved file, save it, reload, and confirm that the key is absent from wg show wg0 peers. Update the revocation ledger with the public key, date, reason, and affected backups. Live removal alone is temporary; file removal alone leaves the currently running peer authorized until applied.［4］

On an authorized test device holding the revoked profile, reconnect and generate new traffic toward a permitted tunnel-only service. It must not obtain a fresh handshake or protected response. Keep a legitimate device as a positive control. If you cannot safely access the revoked device, record that negative client test as unperformed; absence from the server lists is a useful configuration check, not equivalent evidence.

Unexpected traffic volume is a separate investigation. Compare peer ownership, handshake timing and transfer-counter changes over an interval; counters may reset when the interface is recreated and do not identify a human or a particular application. Revoke a confirmed leaked identity, verify denial, then reconcile provider usage and billing. Removing a peer does not stop host rental, snapshots, storage, or other resources from being charged.

Step 5: Which checks survive reboot and recovery?

Schedule an authorized reboot only after unaffected devices and the independent console work. After startup, repeat the live inventory and client checks. If the interface does not start, use the boot lifecycle procedure rather than restoring an insecure old file.

Check method	Expected observation	Failure action
New device sends permitted traffic	Its key is present, a fresh handshake appears, and the service responds	Check the assigned key/address and application path
Unchanged device sends the same request	Its existing access still works	Inspect overlapping ranges and revert the narrow addition
Revoked profile attempts a new connection	Key remains absent; no fresh handshake or protected response	Stop acceptance and remove the identity from every active writer
Authorized reboot repeats these checks	Added peer remains; revoked peer stays absent	Inspect file ownership, generators, and startup failure
Isolated backup recovery applies the ledger before startup	No revoked peer is restored	Correct the restored file before exposing the instance

A failed request alone is weak revocation evidence: a disconnected network can make every device fail. That is why the positive control belongs in the same check window. Record time, interface, tested key identifier, action and evidence without storing secrets in the report.

Step 6: Recover an accidental deletion safely

For a genuinely accidental removal of a still-trusted device, restore only its reviewed peer section and address, reload, and repeat the positive checks. Never restore a known-compromised key to recover convenience; issue a fresh device identity and retire the leaked profile. If broad rollback is necessary, restore the protected file, reapply every later revocation from the separate ledger, verify permissions, then reload or start as appropriate.

Do not overwrite the only backup or erase the ledger during cleanup. Retain backups under your access and retention policy, remove the one-off test identity from both live and saved state when finished, and verify its removal. A host move also needs endpoint and identity decisions; carry this reconciled inventory into the one-client migration workflow.

When the long-term task is maintaining devices for everyday internet access, compare the responsibilities of a VPS and a managed VPN before adding more maintenance work. That decision does not revoke existing keys or cancel the old server's bills.

Summary

Treat the file and running interface as separate acceptance targets.
Allocate one identity and non-conflicting address per device.
Carry revocations forward through reboot, rollback and backup recovery.

FAQ

Does editing the file immediately revoke a peer?

Editing alone does not change the running interface. Remove the live peer or reload the reviewed configuration, then verify denial and persistence separately.

Is reload enough after adding a subnet?

Reload changes WireGuard peer settings but does not create system routes. Review the new subnet's routing and schedule the necessary network change separately.

Should every device share one private key?

Each device should have its own key pair so that ownership and revocation are specific. Sharing an identity makes selective removal unreliable.

Does an old handshake timestamp prove revocation?

An old timestamp can simply mean that the device is idle or offline. Check key absence and use an authorized negative connection test with a positive control.

Can I restore a backup made before a leak?

You can use its trusted configuration only after removing every subsequently revoked identity. An older backup does not know about later security decisions.

Will a replacement public key stop server billing?

Changing a peer key affects authorization, not provider resources. Review compute, storage, snapshots and traffic accounting separately after securing access.

What if I lose the administration connection?

Use the previously verified independent console to inspect and restore the narrow change. Do not continue remote edits through the only failing tunnel.

Sources:

WireGuard — Quick Start — https://www.wireguard.com/quickstart/
Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html
Ubuntu Noble — wg(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg.8.html

Sources checked 11 October 2026.

Related Articles:

WireGuard Peer Management: Add, Revoke, and Save Changes