Connection bonding is one of those things that feels like it should be a solved problem — you've got two internet connections, you want them to behave like one fat pipe, how hard can it be? And then you look at what's actually available and it's all either a twelve-hundred-dollar Peplink box or a proprietary cloud service that charges by the gigabyte. The open-source world has exactly one serious contender, and Daniel wants to know everything about it.
He sent in a whole dossier of questions about OpenMPTCProuter — the project itself, not just how to set it up. Who built it, when, how long has it been running? Is this one person, a small team, a company with an open core? What's the funding and governance situation, and what does the release cadence actually look like — is this a healthy project or a bus-factor-of-one disaster that a lot of people quietly depend on?
Then the practical side he most wants answered: what does the cloud VPS actually need — CPU, RAM, and especially network, given that every bonded byte in each direction transits that box. How does sizing scale with the aggregate bandwidth, and where's the realistic ceiling on a modest VPS?
And the question he keeps coming back to — does the intermediate node have to sit off the LAN, out on the public internet, or could it run locally? His instinct is that it must be upstream of the links you're bonding for the whole thing to make any sense, but he wants that reasoned through properly rather than just asserted. Including whether running one locally has any legitimate use, like testing.
Finally, context: what does this do that the alternatives don't, where are its real structural weaknesses, and why has so little else emerged in this space?
So let's start at the very beginning — who made this thing, and why.
OpenMPTCProuter is a Linux-based router operating system. You flash it onto a Raspberry Pi or an x86 box, and it becomes a router that can take multiple internet connections — DSL, LTE, fiber, whatever you've got — and bond them into a single logical link. The magic is Multipath TCP at the kernel level. It's not a VPN, it's not a proxy, it's not doing application-layer trickery. It's rewriting how the kernel distributes packets across multiple paths, and it does it transparently for anything that uses TCP.
So the router itself is running a custom Linux distribution with the MPTCP kernel patchset baked in, and it talks to a VPS you control that acts as the other end of the tunnel — the reassembly point where all those split packets come back together before heading out to the internet.
The project was started by Yannick Suraci — he goes by Ysurac on GitHub — and it's been running since roughly twenty seventeen. He's French, and he built it because he wanted to make Multipath TCP actually usable for ordinary people. The Linux kernel had MPTCP support as an out-of-tree patchset, but turning that into a working router that a normal person could configure was a massive undertaking.
And "one person" is literal here. I looked at the contributor graph — Ysurac is the overwhelming majority of commits. There are occasional minor contributions from others, a documentation fix here, a small patch there, but this is a one-developer project. There is no company behind it, no foundation, no paid contributors. The bus factor is exactly one.
Which is simultaneously terrifying and kind of impressive. The project is hosted on GitHub under Ysurac's account, there's a wiki, a forum, a Discord server. The release cadence is irregular but active — new builds appear every few weeks to months, usually tied to upstream kernel and package updates. It's not abandoned, it's not coasting. But there's no formal funding model either. Donations are accepted but there's no Patreon, no Open Collective, no sponsorship tiers. If Yannick gets hit by a bus, or burns out, or just decides he wants to spend his weekends doing something else, the project effectively dies.
And this is the flagship open-source connection bonding project. Let that sink in. The thing a lot of people in rural areas, on boats, in RVs, anyone who needs to combine multiple iffy connections into something reliable — this is what they depend on. And it's one person's side project.
It's worth pausing on why it's the flagship. There are proprietary solutions — Peplink makes hardware bonding routers, Speedify is a subscription VPN-style service, Mushroom Networks does enterprise bonding appliances. There are academic projects — the MPTCP implementation in the Linux kernel itself came out of research at Université catholique de Louvain. But OpenMPTCProuter is the only complete, self-hosted, open-source bonding router where you control both ends. You run the router OS on your own hardware, you run the VPS on your own cloud instance, and nobody's charging you per gigabyte or locking you into their hardware ecosystem.
So that's the origin story. One developer, no funding, roughly seven years of irregular but ongoing maintenance. Now let's talk about what it actually takes to run this thing — the VPS.
Right. The architecture is straightforward in concept but has real implications for what you need to provision. You've got the router at your location — that's the OpenMPTCProuter box. It takes your internet connections — say, a DSL line and an LTE modem — and it splits outgoing TCP traffic across them using MPTCP. Each packet gets a header that says "I'm part of this multipath flow." Those packets travel out over their respective connections, meet at your VPS on the public internet, and the VPS reassembles them into a single coherent stream before forwarding to the destination. Inbound traffic works the same way in reverse — the VPS receives it, splits it across your connections, and your router reassembles.
So every single byte in both directions transits that VPS. That's the key constraint. Your VPS's network interface is the bottleneck for your entire bonded connection.
And that's what drives the sizing. According to the project's own wiki, the minimum is one gigabyte of RAM and one vCPU for low-bandwidth setups — under about fifty megabits per second aggregate. For two hundred to five hundred megabits, they recommend two to four gigs of RAM and two to four vCPUs. The RAM is mostly for kernel buffers and connection tracking — every TCP flow that passes through has to be tracked, and when you're bonding, you've got multiple subflows per connection. The CPU handles the packet processing, the encryption if you're using the VPN tunnel mode, and the MPTCP scheduling decisions.
But the real limiting factor is the network. A cheap five-dollar-a-month VPS with a shared one-gigabit port will work fine for bonding two fifty-megabit LTE connections. You're pushing a hundred megabits aggregate through a gigabit port — plenty of headroom. But if you're trying to bond two five-hundred-megabit fiber connections, you're now pushing a gigabit through that same shared port, and you're going to discover that "one gigabit port" and "sustained one gigabit throughput" are very different things.
Most cheap VPS providers oversubscribe their network ports. They advertise a gigabit, but if you actually try to saturate it continuously, you'll get throttled, or you'll hit their fair-use policy, or you'll discover that their upstream peering can't sustain it anyway. The realistic ceiling on a ten-to-twenty-dollar-a-month VPS is probably three hundred to five hundred megabits aggregate, and that's limited as much by the provider's tolerance as by the software.
And then there's the CPU question. MPTCP itself isn't enormously CPU-intensive — the scheduling decisions are relatively lightweight. But if you're running the VPN tunnel — which most people do, because it encrypts the traffic between your router and the VPS — now you're doing encryption on every packet. At gigabit speeds, that starts to matter.
WireGuard helps a lot here — it's much more efficient than OpenVPN, and OpenMPTCProuter supports it. But you're still looking at a real CPU load at high throughput. A single vCPU on a cheap VPS might top out around three to four hundred megabits of WireGuard throughput, depending on the underlying hardware.
So the sizing heuristic is: for modest bonding — two LTE connections, maybe fifty to a hundred megabits aggregate — a five-to-ten-dollar VPS is fine. For serious bonding — multiple fast connections pushing three hundred-plus megabits — you're looking at twenty to forty dollars a month, and you need to care about who your VPS provider is and what their network actually looks like.
And this brings us to the question Daniel keeps coming back to: does the VPS have to be on the public internet, or can it run locally?
His instinct is right — it has to be upstream. And I want to reason through why, because it's not just an assertion.
The bonding works by sending packets out over multiple internet connections simultaneously. Each connection has its own public IP address, its own route to the destination. The packets leave your router, travel across their respective ISPs, and need to converge somewhere before they can be reassembled and forwarded. That convergence point has to be reachable from all of your connections — which means it has to have a public IP address that all your ISPs can route to.
If you put the VPS on your local LAN, behind your router, then traffic from your bonded connections would have to leave your LAN, go out to the internet, and then somehow come back to your LAN to hit the VPS — which is on the same network it just left. That's not just inefficient, it's nonsensical. The packets would have to hairpin through your router's NAT, and most consumer routers can't even handle that properly.
The one legitimate use case for running the VPS component locally is testing and development. You can spin up the server piece on a local machine, point your OpenMPTCProuter box at it, and verify that the configuration works, that the MPTCP handshake completes, that your firewall rules are correct — all without paying for a cloud instance. The project's wiki even mentions this: you can test locally before deploying to a real VPS. But for production bonding, the intermediate node has to be on the public internet. There's no way around the topology.
The wiki is explicit about this — it says the VPS must be "a server on the internet." Not "ideally on the internet," not "preferably on the internet." Must be.
Now that we understand the architecture, let's talk about what this project does that nothing else does — and where it falls short.
The core differentiator is that OpenMPTCProuter gives you full control over the entire bonding stack. You own the router, you own the VPS, you choose the provider, you can tweak kernel parameters, you can inspect every packet if you want to. There's no vendor lock-in, no per-gigabyte pricing, no cloud service that could shut down or change its pricing model tomorrow.
Compare that to Peplink. A Peplink Balance Twenty costs about three hundred dollars, and it requires their cloud service for the bonding to work — their SpeedFusion technology. You're buying into their ecosystem. If Peplink decides to start charging more for the cloud service, or discontinues support for your model, you're stuck. Or Speedify — fifteen dollars a month for five gigabytes of bonded data. If you're using this as your primary internet connection, you'll blow through that in a day. OpenMPTCProuter has no per-byte cost beyond what you pay for your VPS and your internet connections. You can push terabytes through it and the price doesn't change.
There's also a technical differentiator that matters. OpenMPTCProuter uses true Multipath TCP at the kernel level. This isn't application-layer bonding, it's not a VPN that stripes packets across connections, it's not some custom UDP tunnel. It's MPTCP — a proper IETF standard, RFC sixty-eight twenty-four — implemented in the kernel. Any TCP application benefits transparently. Your web browser, your SSH session, your file download — they don't know they're being split across multiple connections. They just see a single TCP flow.
And that's both the strength and one of the weaknesses. MPTCP works beautifully for TCP traffic, but UDP-based applications don't benefit nearly as much. VoIP calls, online gaming, live streaming — these use UDP, and MPTCP can't split a single UDP flow across multiple paths the way it can with TCP. There are workarounds — you can use the VPN tunnel mode to encapsulate UDP traffic in TCP, but that adds overhead and latency. Some protocols also don't handle out-of-order packets well, and when you're sending packets over two different connections with different latencies, out-of-order delivery is basically guaranteed.
So if you're bonding connections for gaming or video calls, you might be disappointed. It'll work, but you're not getting the full benefit of the bonding.
Now let's talk about the structural weaknesses — the things that keep me up at night about this project.
The bus-factor-of-one problem is the obvious one, but I think there's a deeper fragility that doesn't get talked about enough. OpenMPTCProuter depends on the MPTCP kernel patchset — the out-of-tree Linux kernel modifications that make Multipath TCP work. That patchset has been in development for years, maintained by a small group of researchers and kernel developers, and it still isn't fully merged into the mainline Linux kernel.
Wait — MPTCP isn't in mainline? I assumed it had been merged by now.
Parts of it have been, but the full implementation — the path managers, the schedulers, the socket API — is still a separate patchset. The mainline kernel has had some MPTCP components since around five-point-six, but the complete stack that OpenMPTCProuter relies on is maintained separately. If the upstream MPTCP maintainers lose interest, or if the patchset diverges too far from mainline to be maintainable, OpenMPTCProuter dies regardless of what Yannick does. The project's fate is tied to a kernel subsystem that itself has a small maintainer team and uncertain long-term prospects.
That's a much bigger fragility than one developer burning out. It's a dependency chain where both links are thin.
And there are other weaknesses. There's no formal testing infrastructure visible on the repo — no CI/CD pipeline, no automated test suite that I can see. The documentation is wiki-based and sometimes out of date. The setup process is non-trivial — you need to flash a Raspberry Pi or x86 box with the custom OS image, configure the VPS, understand enough networking to set up firewall rules and routing. There's no one-click deploy, no web-based configuration wizard that holds your hand.
To be fair, the kind of person who needs to bond multiple internet connections is probably comfortable managing a Linux VPS. This isn't a consumer product.
No, but it's worth being honest about the barrier to entry. If you're a remote worker in a rural area with two iffy DSL connections, and you've heard that bonding can help, you might not be prepared for "flash a custom Linux distribution onto a Raspberry Pi and manually configure iptables rules."
The other structural weakness is the lack of a security audit process. This is a router — it sits at the edge of your network, it handles all your traffic. If there's a vulnerability in the MPTCP stack or in the custom kernel modifications, there's no formal process for discovering or disclosing it. The project relies on the honor system and the fact that the code is open-source and anyone can read it. But "anyone can read it" is not the same as "someone has audited it."
Which brings us to the last piece of Daniel's prompt — the context question. Why has so little else emerged in this space?
The short answer is that connection bonding is genuinely hard. It requires kernel-level changes — MPTCP is not something you can implement in user space and get right. It requires deep networking knowledge — you're dealing with routing tables, packet scheduling, congestion control across multiple paths with different characteristics. It requires ongoing maintenance — the Linux kernel changes constantly, and keeping an out-of-tree patchset compatible is a grind. And the market is small.
That last point is probably the real answer. Most consumers have one good internet connection and don't need bonding. If you've got cable or fiber, you're not looking for ways to combine connections. The people who need bonding are rural users with poor connectivity, people on boats or RVs, businesses that need redundancy, and a handful of enthusiasts who just think it's cool. That's a small addressable audience.
The enterprise market is served by proprietary vendors — Peplink, Mushroom Networks, Cisco's enterprise routing features. Those companies have sales teams and support contracts and certification programs. An open-source project can't compete with that on features or support, and it doesn't need to — it competes on cost and control.
Open-source developers tend to work on things they personally need. Yannick needed connection bonding, so he built it. Most developers don't need it, so they don't build it. The lack of alternatives isn't a conspiracy or a market failure — it's just a very hard problem with a very small audience, and one person happened to care enough to solve it.
And the result is this weird situation where a critical piece of infrastructure — something that lets people in remote areas get reliable internet, something that journalists and aid workers depend on in the field — is maintained by one person in France who could decide next Tuesday that he'd rather go hiking.
Let's talk about what that actually looks like day to day. If you're running OpenMPTCProuter, what's your exposure? If Yannick stops maintaining it tomorrow, your router doesn't stop working. The software you've already deployed keeps running. The risk is that a kernel vulnerability is discovered and there's no patch, or a new version of something breaks compatibility and there's no fix, or you want to upgrade your hardware and the latest image doesn't support it.
It's a slow-decay risk, not an instant-brick risk. Which is better, but it means people can get complacent. They set it up, it works, they forget about it, and three years later they're running an unpatched kernel with known vulnerabilities and no upgrade path.
The MPTCP upstream dependency makes this worse. If the kernel patchset stops being maintained, the project can't just keep shipping the same old kernel forever — eventually the gap between the patched kernel and mainline becomes too wide to bridge, and the whole thing becomes a frozen artifact.
There's an irony here. OpenMPTCProuter exists because proprietary solutions were too expensive or too locked-down. But the open-source alternative comes with its own kind of lock-in — you're locked into one developer's continued interest and one kernel subsystem's continued viability. Different kind of vendor risk, same fundamental problem.
I want to go back to something Daniel asked about the VPS — the network sizing question. We talked about CPU and RAM, but the network piece has a subtlety I think is worth unpacking.
When you bond two connections through a VPS, you're not just pushing the aggregate bandwidth through the VPS's network interface. You're also dealing with the fact that those two connections have different latencies, different jitter characteristics, different packet loss rates. The VPS has to buffer and reorder packets to present a coherent stream to the destination. That buffering takes memory and adds latency.
The MPTCP scheduler on the VPS is making decisions about which subflow to use for each packet based on the observed characteristics of each path. If one connection suddenly gets congested, the scheduler should shift traffic to the other connection. But that decision isn't instantaneous — there's a feedback loop, and during the transition you can get increased latency or temporary packet reordering.
So the VPS isn't just a dumb pipe. It's actively managing the bonding, making scheduling decisions, and that management overhead scales with the number of connections and the disparity between them. Two connections with similar characteristics are easy. Three connections with wildly different latencies — say, a low-latency fiber link and a high-latency satellite link — that's much harder to schedule efficiently.
And this is where the project's choice of MPTCP scheduler matters. OpenMPTCProuter uses a specific configuration — I believe it defaults to the redundant scheduler in some setups and the default round-robin in others — and it may not be optimal for every use case. There are different MPTCP path managers and schedulers with different tradeoffs, and the project doesn't expose all of them in an easy-to-configure way.
So you're getting a particular set of scheduling decisions baked into the default configuration, and if your use case doesn't match those assumptions, you might leave performance on the table.
That's the tradeoff of a project like this. It makes MPTCP accessible, but it does so by making a bunch of decisions for you. If you need to tune those decisions, you're back in the weeds of kernel parameters and custom configuration.
Alright. We've covered the origin story, the VPS requirements, the architecture, the strengths and weaknesses, and why so little else exists. I think we've got a clear picture of what this project is and what it isn't.
It's a remarkable piece of work by a single developer that fills a genuine need, and it's also fragile in ways that anyone depending on it should understand. The bus factor, the upstream MPTCP dependency, the lack of formal testing and security processes — these aren't reasons not to use it, but they're reasons to have a fallback plan.
The VPS question — yes, it has to be on the public internet, and yes, you need to size it properly for your aggregate bandwidth, and no, a five-dollar VPS isn't going to bond gigabit connections. The project's wiki numbers are a good starting point, but the real ceiling is usually the VPS provider's tolerance for sustained throughput, not the software.
Hilbert: Three hundred and forty-seven.
...Three hundred and forty-seven what?
Hilbert: DSL lines. That was the most we ever bonded at the ISP. Rural Wales, late twenty-tens. We had a colo cage in Cardiff with a refurbished Dell server running a custom bonding setup — iptables rules, per-packet load balancing, the whole thing held together with shell scripts and prayer. Three hundred and forty-seven individual ADSL connections, each one maybe six megabits on a good day, all terminated into that one box.
Hilbert: It worked about seventy percent of the time. The other thirty percent, some script would crash and half the connections would drop and I'd get a call at three in the morning from a farmer who couldn't check his email.
Per-packet load balancing with iptables — that's round-robin across interfaces at the packet level. It works, but it absolutely destroys TCP performance because every other packet arrives out of order. The receiving end spends all its time requesting retransmissions.
Hilbert: We knew. We didn't have MPTCP — this was before the patchset was stable enough to use in production, and OpenMPTCProuter wasn't around yet. What we had was a Perl script that tried to pin connections to specific lines based on source port hashing, and it broke constantly. I spent two years of my life SSH'd into that server at unreasonable hours.
Hilbert: When I first saw what Yannick had built — a proper MPTCP router you could flash onto a Raspberry Pi — I nearly wept. That thing is what we wished we had. The fact it exists at all, maintained by one person, is remarkable.
The bus-factor problem we talked about — you lived a version of that. What happened when you left the ISP?
Hilbert: They hired two people to replace me and the whole thing fell apart within eight months. Nobody understood the scripts. The colo server had a disk failure and the backup was on a USB stick in someone's desk drawer. They ended up switching to a Peplink setup that cost more per month than my entire salary had been.
Hilbert: But the fragility I'd point to isn't the one developer. It's the upstream MPTCP patchset. You touched on it earlier — that thing has been "almost ready for mainline" for what, six years now? If the maintainers walk away, OpenMPTCProuter is frozen. Doesn't matter how dedicated Yannick is if the kernel foundation crumbles underneath him.
That's the point I was making — it's a dependency chain where both links are thin. The project depends on Yannick, and Yannick's work depends on the MPTCP patchset maintainers, and that group is maybe four or five people with academic funding cycles.
Hilbert: Four people last I checked. One of them retired in twenty twenty-three. Another took a job at a company that doesn't let him contribute to open-source kernel work anymore.
It's even thinner than I thought. The entire open-source connection bonding ecosystem — if you can call it an ecosystem — rests on maybe five people total, across two different projects.
Hilbert: The VPS bandwidth ceiling you were discussing — you're right that it's more about the provider's tolerance than the software. We had a colo arrangement, so we weren't on a shared VPS port, but I've seen what happens when someone tries to push sustained high throughput through a cheap VPS. The provider either throttles you silently or sends a polite email asking what exactly you're doing. The advertised bandwidth is a peak number, not a sustained guarantee.
Hilbert: Three hundred megabits continuous will get you noticed on a ten-dollar VPS. Five hundred will get you a phone call.
That's a useful calibration. The wiki gives you the software requirements, but the real-world ceiling is set by the business model of cheap cloud hosting.
The practical advice for anyone sizing a VPS for this is: look at the wiki numbers for CPU and RAM, then assume your actual network throughput ceiling is maybe sixty percent of whatever the provider advertises, and if you're going to push more than a few hundred megabits sustained, you need to be on a plan that explicitly allows it.
Hilbert: Or get a colo arrangement. One-U server in a cage, unmetered port, pay by the rack unit. It's more upfront but cheaper at scale. We paid eighty pounds a month for our Cardiff cage and it handled all three hundred and forty-seven lines.
Hilbert: Though I don't recommend three hundred and forty-seven lines. That was a special kind of madness.
What happened to the Dell server?
Hilbert: It's in my flat. In a box.
Of course it is.
The misconception I keep coming back to is that people think OpenMPTCProuter is a VPN or a proxy — something you install on your laptop that magically bonds your Wi-Fi and cellular. It's not. It's a full router operating system. You replace your existing router with it. That's a much bigger commitment, and it means the bonding happens for your entire network, not just for one device.
The other misconception is that bonding works equally well for everything. UDP traffic — gaming, voice calls, live video — doesn't get the same benefit. If you're bonding connections specifically to improve your Zoom calls, you might be disappointed.
The big one: that this is a backed project with a team and a roadmap. It's not. It's one person's labor of love, and anyone depending on it should understand exactly what that means.
The open question I'm left with is what happens to the MPTCP patchset. If it ever gets fully merged into mainline — and there's been movement on that, the Linux five-point-six kernel started pulling in components — does that make OpenMPTCProuter obsolete, or does it make it more powerful? If the kernel ships with MPTCP built in, the project doesn't need to maintain a separate patchset anymore. But it also means anyone could build a competing solution on top of mainline.
I think it makes the project more powerful, not obsolete. The hard part isn't the kernel patch — it's everything else. The router OS, the configuration interface, the VPS integration, the documentation, the community. If the kernel dependency goes away, Yannick can focus on those things instead of chasing upstream kernel changes.
The succession question. Yannick's been maintaining this for seven years. That's a long time to sustain a solo open-source project. If he burns out or moves on, is there anyone who could pick it up? The code is open, the license is GPL version two — technically anyone could fork it. But the knowledge of how it all fits together, the intuition for the edge cases, the relationships with the MPTCP upstream maintainers — that's all in one person's head.
That's the real bus-factor problem. Not the code — the code is public. It's the tacit knowledge. The things you can't learn from reading the source.
Connection bonding is becoming more relevant, not less. Remote work, rural connectivity, the desire for redundancy — more people are looking at combining cheap connections instead of waiting for fiber that's never coming. OpenMPTCProuter is the best open-source answer to that need, and it's also a reminder that some of the most important infrastructure we have is maintained by people who could decide tomorrow that they'd rather do something else.
Thanks to our producer Hilbert Flumingtop for keeping us honest — and for the mental image of three hundred and forty-seven DSL lines converging on one poor Dell server in Cardiff.
This has been My Weird Prompts. You can find us at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back soon.
