Is WireGuard production ready? The answer is not the protocol

People ask whether WireGuard is ready for production, which sounds like a question about cryptography and is really a question about your environment. The protocol has been reviewed for years; the deployment still has to answer whether your networks carry its transport, who enrolls and retires devices, and who patches the package on both ends. Those answers differ between two servers in one rack and a thousand laptops. The protocol is the same in both cases; the operations are not.

The question behind the question

What people usually want to know is whether they can commit to a design that will not embarrass them in six months. That is a deployment question with four parts, and each part can fail independently of the others. Answering three of them well does not compensate for the fourth.

An old warning about a pre-release snapshot is a fact about that snapshot, not a permanent label on every later package. Equally, no blog post can declare your specific combination of kernel, client, network and staff ready. The work is to make the combination explicit and check it.

Treat readiness as a set of gates that you either pass or record as open. That turns an argument into a checklist with owners. It also makes the open items visible to whoever signs off, rather than buried in a pilot report.

Gate one: the path must carry UDP

WireGuard carries its traffic over UDP and documents that it does not provide a TCP mode or traffic obfuscation. A design that depends on it looking like ordinary web traffic, or on changing the port to obtain TCP behaviour, is built on an assumption the software does not support.

So the first gate is a survey, not a test on one machine. List the access environments your users actually work in, then verify the approved UDP path in each one and decide what happens when it is unavailable.

A connection that works from the office proves nothing about a hotel network, a campus firewall or a mobile carrier that handles UDP differently. Those environments are the reason remote access deployments fail after a successful pilot. The pilot was not wrong; it was narrow. Widening it is the gate.

Write down the fallback too. If the answer is that there is no fallback, that is a decision worth stating in advance rather than discovering during a business trip.

Gate two: someone must own the keys

WireGuard peers authenticate with keys, one pair per participant. That is simple to describe and operationally demanding, because nothing in the protocol enrolls a device, tracks who holds which key or removes access when a laptop is lost. The protocol assumes the keys are already correct, and correctness is somebody job.

Name the person who enrolls a device, the record that maps a public key to a person and a device, and the procedure for removal. If removal depends on remembering where copies of a configuration file were installed, the procedure is not finished.

Choose one device during the pilot and retire it end to end. That exercise produces more useful information than another connectivity test, because it exposes the gaps in your records.

Gate three: the package needs a maintainer

WireGuard can arrive as an in-kernel implementation, as a distribution package or as a userspace client, and each has its own update path. The operating question is which one you run, where it came from and who applies an advisory.

We use WireGuard is not an inventory. It does not identify the package to patch, the version on the gateway or the person who can roll a bad update back.

Gate four: accept the workload, not the handshake

Acceptance criteria should describe what users do. Reaching an internal application, resolving its private name, being refused an unauthorised destination and following the defined behaviour when the tunnel is down are all observable, and a successful handshake is none of them.

Run those checks through a network change, a device restart and a gateway maintenance window, because those transitions are where deployments break.

Keep the evidence beside the criteria, including the local state that produced it:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

A green test on a quiet network with one laptop is a starting observation. It is not a reliability claim, and treating it as one is how a design that works becomes a design that is trusted.