My feeds this week are wall to wall with one thing: WireGuard is going into the mainline Linux kernel. It's queued for the 5.6 release, so it's not in a stable kernel on anyone's machine yet, but the merge has happened and the internet has decided to celebrate now rather than wait. I am celebrating too, with the small caveat that I want to be clear about why, because the reasons being cheered are not always the ones that matter.
The thing people are excited about, on the surface, is that WireGuard is fast and the configuration is tiny. Both true. I migrated my own homelab VPN to it a few days ago and the entire server config was forty lines including comments. But "fast and simple" is not really the news. WireGuard has been fast and simple for ages, as a kernel module you built yourself or pulled from a third-party repo. The news is the four letters: in-tree.
why in-tree is the actual story
When something lives outside the kernel tree, you are signing up for a relationship. The module has to track kernel changes. Distributions have to package it, usually via DKMS, which means it rebuilds against your running kernel and occasionally doesn't, and then your VPN is down after a routine update because an out-of-tree module failed to compile against a header that moved. I have lived that exact morning. It is not WireGuard's fault, it is the nature of code that lives next to the kernel instead of inside it.
In-tree changes the relationship entirely. The code now moves with the kernel. When an internal API changes, whoever makes that change is responsible for fixing every in-tree user, including WireGuard, before their patch lands. You update your kernel and the VPN is simply there, like the rest of the network stack, with no separate build step and nothing to break out of sync. That is the whole prize, and it's an unglamorous one: WireGuard becomes boring infrastructure rather than a thing you maintain.
There is a quieter reason this took as long as it did, and it's worth dwelling on. WireGuard's author held out for going in properly rather than fast. Part of the holdup was that it depended on a cryptography library that needed to be acceptable to the kernel's crypto maintainers, and that meant work, the kind of unsexy plumbing work that doesn't trend. The version that got merged is the version that went through that process honestly. Getting into the kernel is not a marketing milestone, it is a review gauntlet, and the fact that WireGuard chose the slow honest route is exactly why I trust the result.
I want to sit with that for a moment, because it cuts against how we usually talk about software. The pressure everywhere else is to ship, iterate, fix it in the next release. The kernel does not work like that, and WireGuard chose to play by the kernel's rules rather than route around them. It could have stayed a popular out-of-tree module forever, downloaded by the millions, never subjected to a maintainer asking awkward questions about its crypto. It chose the harder door. The reward is small and permanent: it is now part of the thing it runs on, with no asterisk. We reward novelty so relentlessly that it's easy to forget patience is also a feature, and in infrastructure it might be the most important one. A protocol I will trust with every byte between my machines should have taken its time getting into the place it lives.
what it changes for the rest of us
For most people, nothing, for a while. 5.6 has to ship, then distributions have to ship kernels based on it, then those kernels have to reach your machines through whatever update cadence you run. If you are on a long-term-support distribution, in-tree WireGuard might be a year or more away on your servers, and in the meantime the backported module is still how you'll actually run it. So the practical advice today is the same as last week: use the module, it's good, it's stable, I'm running it.
What changes is the direction. A protocol going into the kernel is a one-way door. It signals that this is now the default answer to "how should two Linux boxes talk securely over the internet", in the way IPsec was the default answer for a generation despite nobody enjoying configuring it. The next decade of homelab tutorials, cloud provider VPN offerings, and mesh networking tools will assume WireGuard is just present, the way they assume ip and ss are present. That assumption is what in-tree buys you, and it's why the celebration is justified even though there's nothing to install today.
It's also worth being honest about what in-tree does not mean. It does not mean the code is finished, or that the surrounding tooling is mature on every platform. The kernel module is the easy half; key distribution, peer management, and the question of how a hundred machines find each other and rotate keys are all left as an exercise. The merge is a foundation, not a finished house. The interesting work for the next couple of years happens above it: mesh tools, config generators, the userspace that turns "two peers and a key" into something you can run across a fleet without hand-editing files. That work was waiting on the kernel to settle, and now it can stop waiting.
I have one mild grumble about the discourse, which is the framing of WireGuard as having "killed" OpenVPN and IPsec. It hasn't. OpenVPN will run on networks and middleboxes that mangle WireGuard's UDP, and IPsec is welded into hardware and standards that aren't going anywhere. What WireGuard has done is take the common case, two machines, a tunnel, modern crypto, no ceremony, and make it so cheap to set up that there's no longer an excuse to bodge it. That is enough. Not everything has to be a death, some things are just a better default arriving quietly, by way of a kernel that ships next month.