Bonded connectivity built into your product, on the OS you already ship.

Not on its own. On QNX and embedded Linux targets the SDK is a bonding data plane, so encryption comes from around it rather than from inside it. Three approaches cover most products:

• The payload encrypts itself. TLS for control, telemetry, and API traffic, SRT for video. Most embedded products already do this, in which case there is no gap to close and nothing to add.
• A tunnel runs over the bond. Bring your own, terminate it on infrastructure you control, and every uplink inherits it. The bond carries ordinary IP traffic, so the tunnel does not need to know it is there.
• Terminate the bond on your own server. With a Self-Hosted Server, bonded traffic reaches your network before it crosses anything you do not own, which satisfies many data protection requirements without touching the application at all.

For contrast, the Speedify client on Windows, macOS, Linux, iOS, and Android encrypts bonded traffic with AES-256. The embedded data plane is deliberately smaller than that, and the tradeoff is the reason it fits in an embedded image at all. If none of the three approaches above fits your architecture, tell us the constraint you are working against and we will tell you whether it can be met.

Yes. Packets from one session leave by several paths and arrive out of order, so something has to restore that order before they reach their destination. Without a reassembly point, TCP reads the reordering as packet loss and the bond performs worse than your best single link would have.

You have two options, and neither means building infrastructure:

• Speedify's global server footprint. Already running, nothing for you to operate or maintain. Most products start here and many stay.
• A Self-Hosted Server on your own infrastructure. Bonded traffic reaches your network before it crosses anything you do not own. Common for OEMs with data residency requirements, private networks, or customers who ask where the traffic goes.

You can move between them later without changing anything on the device side, so this is not a decision you need to get right before a pilot.

Image. 4.1 MB installed on the device, or 2.0 MB as a compressed package download. Nearly all of that is the daemon: the web UI is compiled into the binary at 48 kB, and the router panel, tuning service, and init scripts add roughly 7 kB. It links statically, so nothing else installs alongside it, and the management and terminal interfaces are compile-time options a production build can drop.

CPU. On a four-core appliance running a two-link bond in default configuration, upload throughput measures 1.31 Gbps with the busiest core at 92 percent. That figure is the data plane working near the ceiling of that hardware, not a resting cost.

The useful way to estimate your own target is to start from the aggregate throughput your product actually needs rather than from how many modems it carries, because load tracks packet rate. A telematics unit moving a few Mbps of telemetry plus a periodic model download sits nowhere near the measurement above. A gateway saturating several hundred Mbps of bonded uplink is a different problem, and one worth working through while the SoC is still open.

Send us the target hardware and the throughput profile and we will tell you whether it fits, including when it does not.

A small amount. Traffic runs through the bond and is reassembled in order on arrival, which costs something against a single link that is behaving perfectly.

The more useful comparison is against a single link that is not: during a handover, an obstruction, or a modem failure, its effective latency is unbounded, because the packets are not arriving at all. That is the situation bonding is designed for, and it is where the small steady-state cost pays for itself.

While the bond is saturated, send buffers are capped from each link's measured bandwidth-delay product, so latency stays bounded rather than climbing the way an unmanaged bond does.

Then the device is offline, the same as it would be with a single link. Bonding changes how often that happens, not whether it can.

The reason it helps is that independent radios fail for independent reasons. A Wi-Fi roam, a carrier handover, and a satellite obstruction are uncorrelated events, so all of them coinciding is far less likely than any one of them happening on its own. In practice that turns most total outages into partial ones, where capacity drops and the session continues.

The remaining question is what the device does while it waits, and most connected products already have an answer: a safe state, a cached configuration it can run from, a store-and-forward buffer that flushes when a link returns. Teams often find this gets easier to design with bonding in place, because they are covering a rarer and shorter event than before. We are glad to work through where that boundary should sit for your product.