Daniel's got a travel router, an eSIM, and a nagging feeling that the last mile is held together with hope. His hardware is settled — a GL.iNet Mudi — but the bonding layer is not. He wants a verdict, not a survey.
And he's got a very specific architecture in mind that I think a lot of technically-minded people arrive at intuitively. He wants to own both ends. He's asking whether there's a product where you buy a license for the client on your travel box and a license for the relay on your own VPS, and that's it — you own the whole stack, you pay for software not a service, and the relay is yours. He wants to know if that's a real product category or something he invented.
He's also got constraints. Technically capable, willing to run a VPS, paying out of pocket, but emphatically unwilling to run a research project. So he's asking: given all that, what should I actually use as the bonding layer? Speedify as a black box, or something self-hosted in the cloud? And he wants the reasoning that gets to the pick.
So today we are going to give Daniel his verdict. But first we have to understand what the bonding layer actually is, and why the licensing model he's imagining might not exist the way he thinks.
Let's start there. What is a bonding layer? Because I think most people hear "bonding" and picture two internet connections with a piece of tape between them.
It's not a VPN. That's the first thing to get clear. A bonding layer is a packet-level multiplexer. It takes multiple internet connections — Ethernet, cellular, Wi-Fi — and splits your traffic across all of them simultaneously, at the packet level or the flow level, then reassembles and reorders everything on the far side so it looks like one stable connection to whatever application you're using.
So it's not failover, where you switch when one connection dies.
Right. Failover is reactive. Connection one drops, you wait a few seconds, connection two picks up. Zoom freezes, your SSH session drops, you reconnect. Bonding is proactive — it's using all the links all the time. If one link stutters, the other links carry the load and the far end reassembles the stream before the application even notices. The user sees a single, stable IP address with consistent latency.
And this matters for a travel router because...
Because hotel Wi-Fi drops. Cellular handoffs between towers cause hiccups. The Ethernet jack in the Airbnb is actually two megabits per second shared across fifty rooms. A single connection can't mask those disruptions — the application sees every one of them. A bonding layer hides all that churn. Your Zoom call stays up. Your RDP session doesn't freeze. Your SSH terminal doesn't hang.
So the bonding layer is the thing that makes multiple bad connections look like one good one. And there are two broad ways to get it.
Two categories. One: a managed service where the relay — the far-end box that reassembles your packets — is someone else's server. Speedify is the canonical example. You pay a subscription, you install their client, and your traffic goes through their infrastructure. Two: self-hosted, where you run the relay on your own VPS. OpenMPTCProuter is the main open-source option here. You provision a cloud box, install their software on both ends, and you own the whole path.
So the choice is between renting the infrastructure or owning it. That's the framing Daniel walked into this with.
And it's the right framing. But the details get complicated fast. Let's walk through Speedify's model first.
Okay. What are you actually buying when you pay Speedify?
As of mid-twenty-twenty-six, the unlimited plan is twelve fifty a month or ninety-nine dollars a year. That gets you the client software and access to their relay infrastructure. The relay is a black box — you have no visibility into its routing, no control over its geographic placement, and no guarantee it won't be changed or retired. Speedify uses a proprietary bonding protocol, not MultiPath TCP. They do their own packet duplication, forward error correction, and jitter buffering. It works well out of the box. You install it, you're bonded in fifteen minutes.
Proprietary protocol. So you can't inspect what it's doing.
You cannot. You don't know how it's making decisions about which packets go where. You don't know what their forward error correction algorithm looks like. They have servers in roughly thirty-five regions globally, but you can't choose which one handles your traffic — it's automatic based on latency. You're renting the whole stack, and the stack is opaque.
Which is exactly what bothers Daniel. He wants visibility. He wants to know what's happening to his traffic.
And that's the tension. Speedify's bonding is genuinely good. Their jitter buffering and FEC are well-implemented. It recovers from packet loss gracefully. But you pay with opacity and a recurring cost. And if Speedify changes their infrastructure or their pricing, you have no recourse — you don't own any of it.
So what's the alternative? OpenMPTCProuter?
That's the main self-hosted option. It's open-source software. You install it on a VPS — that's your relay — and you install the client on your travel router. The relay runs a modified Linux kernel with MultiPath TCP support, plus a web UI for monitoring. The client side can run on GL.iNet routers like the Mudi or the Beryl AX, either through custom firmware or a Docker container.
And what does that get you?
You own both ends. You see every packet. You can SSH into the relay and tweak kernel parameters. You choose the VPS provider, you choose the geographic region, you control the routing. If you want to run a packet capture, you run a packet capture. There's no black box.
At what cost?
A Hetzner instance with one vCPU and one gig of RAM runs about six dollars a month. A Linode instance is around ten. That's sufficient for a single user — the bottleneck is usually the VPS's outbound bandwidth, not the CPU. So the recurring cost is lower than Speedify. But the setup cost is real.
How real?
You need to compile or flash firmware. You need to configure MPTCP path managers. MPTCP requires kernel support on both ends, so you're dealing with kernel modules and potentially custom builds. The initial setup is a weekend project for someone who knows Linux. And then there's ongoing maintenance — kernel updates, VPS patching, firmware rebuilds when the upstream project changes something.
So it's not set-and-forget.
It is not. If the VPS goes down at two in the morning during a trip, you're fixing it. If a kernel update breaks MPTCP, you're rolling back. That's the trade-off. OpenMPTCProuter gives you full ownership and visibility, but it demands ongoing attention. It is, to use Daniel's phrase, a second hobby.
And he explicitly said he doesn't want that.
He did. So we've got Speedify on one side — works great, black box, recurring cost. OpenMPTCProuter on the other — full control, lower recurring cost, but real maintenance burden. Is there a middle ground?
I was about to ask that. Something that gives you control over the relay without the kernel-compilation hobby?
There's a category that sits between them. WireGuard-based multipath solutions. Things like the wireguard-multipath project, or Mullvad's experimental multipath feature. These don't bond at the packet level — they bond at the tunnel level. Each flow goes down one path, and if that path dies, the flow fails over to another.
So it's not true bonding.
It's not. No packet duplication, no latency hiding at the packet level. If a path degrades slowly rather than failing outright, you feel it. But it's simpler to set up. You run your own WireGuard server on a VPS — that's your relay — and the client sends traffic across multiple WireGuard tunnels. You own the relay. You see the traffic. The setup is a few config files, not a kernel rebuild.
And Mullvad's version?
Mullvad's multipath is a service, not a self-hosted option. But the architecture is instructive. It shows that tunnel-level bonding is easier to implement but less powerful than packet-level bonding. You get control over the relay with Mullvad — sort of, it's their servers — but you don't get true bonding. It's a different trade-off.
So none of these are what Daniel actually asked for. He wants packet-level bonding with a relay he owns, paid for with a software license rather than a service subscription.
Let's address that directly. Is there a product category where you buy a software license for both the client and the relay, owning both ends, rather than paying for a service?
I'm going to guess the answer is no, because if it existed you'd have led with it.
The answer is no. Not as a commercial product. Peplink's SpeedFusion comes closest, and it's worth walking through why it still doesn't fit. With Peplink, you buy the hardware — a Peplink router, anywhere from two hundred to two thousand dollars — and you can run your own SpeedFusion hub on a VPS using their firmware. But the licensing is per-device and per-feature, and the hub software is not sold separately. It's bundled with enterprise support contracts starting at roughly five hundred dollars a year for the lowest tier.
So even the closest thing is still a recurring service model, just dressed differently.
There is no "buy a client license and a relay license, run them on your own hardware, never pay again" product on the market. And there's a structural reason for that.
Which is?
The bonding layer is inherently a service, not just software. The relay needs to be a well-connected server with good peering, low latency to multiple transit providers, and enough bandwidth to aggregate your connections. If someone sold you a relay license without providing the infrastructure, the support burden lands on them anyway. "My relay is slow." Well, upgrade your VPS. "My relay has bad peering to my hotel in Jakarta." Well, pick a different VPS provider. The economics don't work for a small vendor. Speedify and Peplink make money on the recurring service because the relay costs them money to operate.
So Daniel invented a product category that makes perfect sense from the buyer's perspective and no sense from the seller's.
That's exactly what happened. The thing he wants — own both ends, pay once, no recurring service dependency — exists, but only as open-source software. OpenMPTCProuter. You pay nothing for the software, you pay six to ten dollars a month for the VPS, and you own everything. The catch is the one he already ruled out: you are the sysadmin.
Which brings us to the verdict. Given his constraints — technically capable, wants control, willing to run a VPS, unwilling to run a research project, paying out of pocket — what should he actually use?
I've thought about this a lot, and I think the answer is Speedify, but not in the way most people use it. The recommendation is a specific architecture. Run Speedify on the travel router — the GL.iNet Mudi or Beryl AX, both of which support Speedify natively or through a Docker container. Accept the black box for the bonding layer. That handles the hard problem: packet-level bonding with good forward error correction and jitter buffering, working out of the box. Then run a separate WireGuard VPN from the Speedify exit to your own VPS.
So two hops.
Two hops. The travel router runs the Speedify client. Traffic gets bonded across whatever connections are available — Ethernet, cellular, Wi-Fi — and exits through Speedify's relay. Then, from that exit point, a WireGuard tunnel carries the traffic to Daniel's own VPS, where he can inspect it, filter it, run Pi-hole for ad blocking, whatever he wants. From the VPS, it goes out to the internet.
So the bonding layer is a black box, but the traffic inside it is encrypted again through a tunnel he controls.
Right. Speedify sees encrypted WireGuard traffic, not his actual browsing. He gets Speedify's excellent bonding and FEC for stability, plus his own relay for visibility and control. The cost is Speedify's subscription — ninety-nine dollars a year — plus the VPS, which is six to ten dollars a month. Total is under twenty dollars a month.
And the maintenance burden?
Near zero on the bonding layer. Speedify handles itself. The VPS needs the usual patching — any Linux box does — but that's fifteen minutes a month, not a research project. WireGuard is essentially maintenance-free once it's configured. This is not a second hobby.
Why not OpenMPTCProuter? On paper it's exactly what he asked for.
On paper it is. In practice, it's the right architecture but the wrong effort level for someone who explicitly said "not a research project." The setup friction is real. Compiling firmware for a Mudi is not trivial. MPTCP path managers are finicky. Kernel updates break things. And for a single traveler in hotels and Airbnbs, the performance gains over Speedify are marginal. Speedify's proprietary protocol is good — their FEC and jitter buffering are well-tuned. You might squeeze out slightly lower latency with a self-hosted MPTCP relay in the same region as your VPS, but the difference for Zoom calls and SSH sessions is negligible.
The calculus changes if you're running a remote team or a sailboat.
Completely. If Daniel had five people relying on this connection, or if he was on a boat with satellite links, OpenMPTCProuter wins. You need the visibility and control when the stakes are that high. For one person in an Airbnb with spotty Wi-Fi and a cellular backup, Speedify plus WireGuard is the pragmatic sweet spot. It works, you own the part that matters for privacy and control, and you're not debugging kernel modules at midnight.
The verdict is: Speedify on the router, WireGuard to a personal VPS, total cost under twenty dollars a month, maintenance burden minimal, control over everything that happens after the bonding layer.
That's the pick. It's not the purist answer. The purist answer is OpenMPTCProuter. But Daniel didn't ask for the purist answer — he asked for the answer that works for someone in exactly his position.
The thing he invented — the buy-once-own-both-ends software license — doesn't exist because the economics of running a relay make it a service whether the vendor admits it or not.
The relay costs someone money every month. Either you're paying a vendor to run it, or you're paying a cloud provider and administrating it yourself. There's no third option where you pay once and the relay runs itself for free. That's the shape of the thing.
Which is what he asked us to make sense of.
Hilbert: Nineteen ninety-nine. I was running bonded satellite links on a cruise ship in the Caribbean. Cisco box the size of a mini-fridge. Cost forty thousand dollars. Dropped packets every time a cloud passed over the Atlantic, which, on the Atlantic, is most of the time.
What was the bonding protocol?
Hilbert: Proprietary. Cisco's thing. Multilink PPP with some satellite-specific tweaks they never documented. The vendor charged us eighteen hundred dollars a month just for the support contract, and that didn't include software updates. Those were extra.
You're telling us this because...
Hilbert: Because Daniel is trying to solve the same problem with a hundred-dollar router and a six-dollar VPS. The fact that this is even a question — that the answer isn't just "pay the enterprise tax and shut up" — is remarkable. But I think you're overcomplicating it.
How so?
Hilbert: Speedify is fine. The WireGuard tail is fine. The architecture works. What Daniel actually wants is not a bonding layer. He wants to feel like he's in control. That's a psychological problem, not a networking one. And no software license is going to fix it.
You're saying the whole premise of the question is wrong?
Hilbert: I'm saying if he sets up OpenMPTCProuter, he'll be unhappy anyway. He'll find something else to tweak. The path manager. The congestion control algorithm. The kernel scheduler. There's always another knob. The bonding layer is a solved problem. The anxiety about it is not.
That's... I don't think that's entirely fair. Wanting to see your own packets is not just anxiety.
Hilbert: I didn't say it was just anxiety. I said it was psychological. There's a difference. He wants the thing to be his. He wants to understand it completely. That's admirable. But at some point the thing has to just work, and Speedify does that. The WireGuard tail gives him the visibility where it matters — his own traffic, his own DNS, his own exit point. The bonding layer underneath can be a black box because bonding is a mechanical problem, not an inspection problem.
The bonding layer doesn't need to be transparent because it's not where the trust boundary lives.
Hilbert: Trust the bonding to bond. Inspect everything after. He already has the architecture for that. He just doesn't like that the first hop belongs to someone else.
You think that's just a feeling he should get over.
Hilbert: I think it's a feeling that costs more to indulge than it's worth. I spent three years fighting with a forty-thousand-dollar box that was supposed to be the best money could buy, and it still dropped packets when the weather turned. The fact that Daniel can get better performance from a service that costs eight dollars a month and a VPS that costs six is... I mean, that's not a problem. That's a miracle. He's worried about the wrong thing.
He's worried about control when he should be worried about whether his Zoom call stays up.
Hilbert: The Zoom call will stay up. That's what the bonding layer is for. The control lives somewhere else. He's already designed the right system. He just hasn't accepted that it's the right system.
There's something in that. The architecture we recommended — Speedify plus WireGuard — it separates the concerns cleanly. Bonding is a transport problem. Visibility is a trust problem. You don't need to solve both in the same layer.
Hilbert: You don't. And trying to is how you end up with a second hobby.
I still think there's a legitimate desire for a product that does both. The fact that it doesn't exist doesn't mean the desire is wrong.
Hilbert: I didn't say it was wrong. I said it was psychological. Those aren't the same thing.
The misconception here — and I think this is what Daniel was really asking us to untangle — is that bonding and visibility are features of the same layer. They're not. Bonding happens at the packet level, where the decisions are mechanical: which path has lower latency, which packet needs to be duplicated, how much forward error correction to apply. Visibility happens at the traffic level: what domains am I hitting, what's my DNS resolving, is anything leaking. Those are different problems with different solutions. Conflating them is what makes you think you need to own the relay.
Once you separate them, the answer becomes obvious. Rent the bonding. Own the inspection. That's the architecture.
That's the architecture. Speedify for the bonding layer — it's the best packet-level bonding available to consumers, and its proprietary protocol outperforms vanilla MPTCP in lossy conditions. WireGuard to a personal VPS for the trust boundary. Total cost under twenty dollars a month. Total setup time, maybe an afternoon. Ongoing maintenance, patching a Linux box once a month. That's the verdict.
The product Daniel invented — the buy-once license for both ends — doesn't exist because the relay always costs someone money to run. The only way to own both ends without a recurring cost to a vendor is to be the vendor yourself. That's OpenMPTCProuter. And being the vendor yourself is, by definition, a second hobby.
Which he explicitly ruled out.
The question I'm left with is whether the bonding layer eventually just becomes a commodity feature built into every travel router. GL.iNet is already shipping Speedify integration on some models. Multi-WAN is becoming standard on consumer gear. As eSIM data prices keep dropping, the need for a separate bonding service might just evaporate.
Possibly. But we're not there yet. Hotel Wi-Fi is still terrible. Cellular handoffs still cause hiccups. The problem Daniel has is real, and the answer today is Speedify plus a VPS WireGuard endpoint — not because it's perfect, but because it's the closest thing to "works and you own it" that doesn't require becoming a network engineer in your spare time.
Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the cruise ship story we're definitely going to hear more about later.
This has been My Weird Prompts. If you have a weird prompt, email the show at show at my weird prompts dot com.
We'll be back soon.
