Self-Hosted WireGuard vs Commercial VPN: The Route I Controlled Was the One I Couldn’t Repair

My WireGuard tunnel stopped responding twelve minutes before I had to send a confidential payroll file. I was sitting near Gate 32 at São Paulo–Guarulhos Airport, waiting for an overnight flight, with a 286-megabyte encrypted archive ready for the client’s finance director. I blamed the airport Wi-Fi, reopened its login page and restarted the tunnel. The app showed no recent handshake. I tried my phone hotspot. Still nothing.

At home in Manchester, a small computer ran my WireGuard server.

For nearly two years, it had been one of my most satisfying pieces of infrastructure. I controlled the hardware, generated the keys and knew exactly where my traffic left the internet.

When I traveled, my laptop connected back to the house. Hotel and airport traffic emerged through my residential connection instead of directly through the public network.

There was no subscription renewal.

No commercial account dashboard.

No shared exit server.

The setup worked so quietly that I had started treating it as permanent.

Now I was more than 5,000 miles away, and the route I controlled had disappeared.

The airport Wi-Fi was not the failure

Ordinary websites opened.

The client’s secure transfer page loaded.

Email synchronized, and the finance director’s latest message appeared:

Please upload before 22:00 UK time so payroll can be approved tonight.

The airport network was crowded but usable. My phone’s mobile connection also worked.

Only the home tunnel failed.

I checked the WireGuard status again.

No handshake.

No received data.

The server address was managed through dynamic DNS, so a routine change to my residential IP should have updated automatically. I confirmed that the hostname still resolved, then opened the home router’s companion app.

The router was online.

The broadband connection was active.

Nothing in the house appeared to have lost power.

Then I noticed the router’s new WAN address.

It began with 100.72.

That was the clue that moved the problem from my airport chair to the broadband connection at home.

My server was running behind a locked entrance

The internet provider had changed the neighborhood connection during a network upgrade two days earlier. Ordinary browsing at home continued, so no one in the house noticed.

My self-hosted server did.

The new address belonged to the shared range used for carrier-grade NAT. It allowed the provider to place several households behind shared public addresses, but it removed the direct public entrance my port-forwarded WireGuard server depended on. (IETF)

The server was running.

The router was running.

The dynamic DNS service was running.

But the airport no longer had a reachable path into the house.

That explained why switching from Wi-Fi to mobile data had achieved nothing. The broken part was waiting at the other end.

I had built the tunnel correctly.

The network around it had changed.

The configuration could not repair the missing doorway

I checked the settings anyway.

The keys were correct.

The allowed routes were correct.

The server port had not changed.

Persistent keepalives were enabled too. They can help preserve an existing path through NAT or a firewall, but they cannot create a public entrance when the home connection no longer has one. (WireGuard)

The possible repairs arrived in my head all at once.

I could rent a virtual server and make the home machine connect outward to it.

I could build a relay.

I could ask the ISP for a public address.

I could redesign the setup around IPv6.

All were reasonable projects.

None could be designed, tested and trusted before boarding began.

That was the first real change in my judgment.

Self-hosting had given me control of the tunnel.

It had also made every dependency beneath that tunnel my responsibility.

The hardest part was being somewhere else

Had I been in Manchester, I could have called the provider, changed the router configuration or rebuilt the connection around a relay.

From the airport, each option depended on someone else entering the utility cupboard and following instructions over a video call.

My partner was home but preparing dinner for two children.

I sent one message:

Has the broadband company changed anything?

The reply came a minute later:

New router settings on Tuesday. Internet seems normal. Do you need me to unplug something?

I pictured the small computer, switch, router and power cables stacked on the shelf.

“No,” I wrote. “Leave it.”

Self-hosters often describe the same unpleasant discovery: the system is still theirs, but the repair is physically somewhere else. (Reddit)

That was enough to clarify the risk.

I had designed the tunnel to remove dependence on a VPN company.

The payroll deadline now depended on my home ISP, router, server, house power and ability to repair all of them from an airport seat.

The payroll file did not need my house

I almost kept troubleshooting because the self-hosted route felt like the more principled solution.

Then I asked a simpler question:

Did the finance director need the file to arrive from my Manchester connection?

No.

The company required an encrypted transfer from a protected device. I had used the home tunnel because it gave me a familiar route on public Wi-Fi.

I did not need the home NAS.

I did not need a residential IP.

I did not need to reach anything inside the house.

I needed a secure full-device connection that was available immediately.

That separated two jobs I had been treating as one.

My self-hosted WireGuard tunnel was excellent for reaching my own network.

The payroll upload required dependable protection without relying on it.

Once I saw that distinction, reviving the home endpoint was no longer the best use of the remaining time.

The commercial backup did not need Manchester

I had installed OnlydogVPN^↗ before the trip but rarely opened it.

The home tunnel gave me more personal control, while the largest commercial providers offered longer histories and more locations. The smaller service had fewer regions, ratings and independent reviews, which was why I had kept it as a backup rather than replacing my own setup.

At Gate 32, being the backup was exactly the job available.

I selected the preset for sensitive work on an unreliable public network.

The connection established on the airport Wi-Fi.

Email continued updating.

The secure transfer application authenticated.

I selected the payroll archive and started the upload.

It passed 10 percent.

Then 25.

Then 50.

The departure board changed our gate from 32 to 36, and passengers around me began closing laptops and lifting bags.

The upload reached 71 percent.

I carried the open laptop to the new gate and placed it on a standing desk near the window.

The transfer continued.

At 100 percent, the client portal began verifying the archive.

A checksum appeared.

Then the status changed to:

Upload complete — ready for review.

I sent the finance director the receipt.

She replied:

Received. Payroll approval can proceed.

The task was complete.

My home server was still unreachable, but the file was where it needed to be.

Availability mattered more than ownership

The service uses an HTTP/3-based connection designed to remain usable on weak or changing networks.

The practical difference needed little explanation.

My self-hosted tunnel depended on one endpoint in one house, behind one residential provider.

The commercial route was ready without asking that house to participate.

I could not observe the ISP’s internal migration decisions beyond the shared address assigned to my router. I could observe the result: the home server had no reachable entrance, while the managed route connected and carried the payroll file.

For this situation, independence from my home infrastructure mattered more than personally controlling that infrastructure.

That did not make self-hosting pointless.

It clarified what I had built.

My WireGuard server was a powerful route into and through my house.

It was not a managed network with alternative routes available while I traveled across an ocean.

The airport changed networks before boarding

A boarding announcement began while I was downloading the upload receipt.

The gate Wi-Fi weakened as more passengers gathered around it.

Then the connection disappeared.

My laptop switched to the phone hotspot.

The VPN recovered on mobile data.

The client portal remained signed in, and the receipt finished downloading.

A second message arrived from the finance director:

Could you confirm the employee-count total on page three?

I opened the encrypted local copy, checked the number and replied before joining the boarding line.

That recovery was smaller than the upload itself, but it gave me another reason to keep the commercial app installed.

The first problem had been a dead home endpoint.

The second was an airport network changing underneath an active session.

The backup handled both without involving anyone in Manchester.

Control included every maintenance job

Self-hosting discussions often describe control as an uncomplicated advantage.

I understood why.

I chose the operating system.

I generated the keys.

I could inspect the configuration.

I decided when to update the server and which devices could connect.

Those benefits remained real.

But control also meant that an ISP change became my migration project.

A router failure became my hardware problem.

A power cut became my outage.

A broken domain record or firewall rule became something I had to notice and repair.

When I was at home, I liked that responsibility.

At an airport with a payroll deadline, it felt different.

The commercial service required trust in an outside operator and gave me fewer personally controlled details. In return, I did not have to keep one particular computer, address and broadband line reachable from every place I might travel.

That was not a contest between technical and nontechnical users.

It was a decision about who carried the operational burden.

The receipt settled the comparison

My home WireGuard server remained valuable.

After the ISP restored a public address, I updated the configuration and regained access to the private devices in the house. For reaching my own network, the self-hosted tunnel still did something a normal commercial VPN was not meant to replace.

But it had failed the airport test.

The smaller commercial backup had fewer locations and a shorter public history than the largest providers. It also needed no functioning router, server or public address at my home.

It connected, carried the payroll archive and recovered when the airport Wi-Fi handed the session to mobile data.

I had begun the evening thinking the choice was between owning my VPN and renting one.

The upload receipt revealed the more useful distinction: I owned every part of the home tunnel except the ability to repair it from Gate 36.