How FORGE compares

Same idea. Different engineering.

Bonding multiple links into one resilient connection isn't new. What's new is a platform that keeps your traffic entirely on your own infrastructure, with no vendor cloud in the path, tells you the truth about every link, runs on hardware you already own, and was hardened by breaking it on purpose. Here's how FORGE's approach differs from the three ways this problem is usually solved.

we don't name competitors; we compare approaches. every FORGE figure below is measured and reproducible.
No cloud dependency

Your tunnel begins and ends with you.

Most bonding platforms route your traffic through their servers in their datacenter to bond it, so your packets transit someone else's cloud. FORGE does not. The encrypted tunnel starts on your spoke and terminates on your hub, both machines you own and operate. No third-party relay. No vendor cloud in the data path. No traffic handed to a datacenter you don't control. For agencies and operators who cannot legally or operationally let sensitive traffic leave their custody, this is the difference between a platform they can deploy and one they can't.

END TO END
Spoke to hub, no waypoint in between.
YOUR INFRASTRUCTURE
No relay servers to trust, subscribe to, or depend on.
DATA SOVEREIGNTY
Your traffic never enters a third party's network.
The category map

Three ways this problem gets solved today.

A
Traditional failover
the enterprise-router default
Multiple WANs, but only one carries traffic at a time. When it fails, a backup takes over, and every live session (VPN, voice, video) drops and reconnects because your public IP changes. Reliable for email; painful for anything real-time.
The gap: failover is not seamless.
B
Router-native bonding
vendor appliances
Real packet-level bonding that keeps sessions alive; genuinely capable. But you buy their hardware and only their hardware, the bonding features are locked behind a mandatory annual subscription that disables your tunnel if it lapses, and the admin interface assumes a network engineer.
The gap: locked in, and hard to run.
C
DIY / open-source bonding
free and powerful
Excellent throughput for the price of your time. But you assemble the hardware, stand up and maintain your own relay server, and become your own support team, and several of these stacks can't fail over cleanly from a cold start if the wrong link is down at boot.
The gap: you are the integrator and the SLA.
The pain-point table

The problems buyers actually hit, and FORGE's answer.

The common experience
How FORGE answers
"My traffic has to go through the vendor's cloud."
Bonding happens on the provider's relay servers: your data transits a third-party datacenter, and the whole thing stops working if their cloud does.
No cloud dependency, period. The tunnel begins on your spoke and ends on your hub, both hardware you own. Your data never touches a datacenter you don't control, and there's no external relay whose outage can take you down.
"It stops working without internet access to the vendor."
Cloud-managed platforms need to reach an activation server or management cloud; lose that path and licensing, config, or the tunnel itself falls over.
No phone home. None. Licensing is validated on the box against a signed fingerprint: no activation server, no license heartbeat, no telemetry. FORGE installs, enrolls, bonds, and routes indefinitely on a network with no way out. Air-gapped operation is the design center, not a stripped-down mode.
"Is bonding even working? I can't tell."
Diagnostic tools exist but interpreting them takes expertise the platform never taught you.
Every link's state is written in plain English on one screen: "601 ms is 1136× the fastest link; held for failover." Green means a path is truly carrying traffic, verified by live probe, not just plugged in. A non-specialist can read it.
"My subscription lapsed and bonding stopped."
Bonding features gated behind a mandatory annual fee that bricks the tunnel if it expires.
One per-HUB license, with no feature paywall that disables a running tunnel. If a license lapses there's a grace period, and even past it the connection is only degraded, never severed: bonded paths are added back on renewal, not the tunnel torn down and replaced. Your traffic keeps flowing; it just runs leaner until you're current.
"I'm locked to one vendor's hardware."
The bonding software only runs on the appliance you bought from them.
FORGE is software. It runs on commodity x86 hardware you own and procure through your own channels. A dead unit is a firmware flash on any conforming box, not an RMA.
"Bonding a satellite link wrecks my latency."
Aggregated latency tracks the slowest link; vendors warn to keep bonded links within ~150 ms of each other.
FORGE benches an out-of-family path automatically the instant it would drag the bond down. If that path is carrying the tunnel's anchor connection, FORGE rebuilds the connection onto the best healthy path. A slow satellite link becomes instant failover, not a tax on every packet.
"No seamless failover from a cold start."
If the wrong link is down when the system boots, the tunnel won't form.
FORGE detects when the tunnel's anchor is riding a degraded or wrong link and moves it automatically, and brings links into the bond as they appear. Cold-start and mid-life link changes both self-heal.
"Failover takes seconds and drops packets."
Detection windows of several seconds mean in-flight traffic is lost.
Measured, each on its own: a WAN cut mid-stream drops zero packets as traffic shifts in-flight; cutting the hub’s uplink puts every spoke back on both paths in ~3.5 seconds; a silent ISP failure with the link light still green is caught in ~14 seconds by live probing. Losing the hub itself is a different mechanism — next row.
"If the hub goes down, every site goes down."
A single concentrator is a single point of failure, and moving sites to a second one is a manual, per-site job.
Hubs federate, and each spoke carries a signed standby assignment. When its home hub stops answering on every WAN, the spoke moves itself to that alternate with no operator input and no ticket. How long that takes, and the limits we deliberately put on it, are in Straight Talk below — measurements and decisions both live in one place on this page, so they cannot drift apart.
"An unstable link keeps thrashing my tunnel."
A flapping connection churns the bond.
A link that drops repeatedly in a short window is automatically benched under escalating probation and only reinstated after it proves itself clean.
"I can't get my monitoring data out."
Telemetry locked inside a vendor cloud.
Syslog-over-TLS to any standards-compliant SIEM, SNMPv3 to your NMS, honest severities in the logs. Your NOC sees your data.
Straight talk

What we don't have, and what we chose not to build.

Two different lists, and vendors usually blur them. The first is where we're genuinely behind. The second is engineering we decided against on purpose and do not intend to add. You deserve to know which is which before you buy.

1 · Where we're behind

The established platforms in this space have a decade of field deployments, large support organizations, and government certifications we're still on the roadmap toward. FORGE is validated on a faithful WAN-emulation rig, with a live-radio field trial as our next milestone. What we offer today is a fundamentally better architecture for resilience and operator truth, a platform you can run on your own hardware, and an engineer who answers the phone. If you need a vendor with a thousand existing installs, that's a real reason to look elsewhere. If you want the platform that was built by breaking it and shows you the truth, book the demo and break it yourself.

2 · What we chose not to build

These are not gaps in a roadmap. They are decisions, and a competitor's datasheet will list several of them as features we lack.

Failback is never automatic.
A site that has failed over stays on its alternate until an operator schedules the return. Coming home is a second interruption, and it should happen in a window your NOC and your site agreed on — not the moment a hub looks healthy again.
One hub at a time. Break, then make.
A site holds a tunnel to exactly one hub. We detect the loss, establish to the assigned alternate, then resume. No make-before-break, no dual attachment, no overlapping sessions to reconcile afterwards.
Alternates are ordered by your NOC, not by latency.
Failover follows the order in a signed assignment, gated on whether the hub actually answers. The closest hub is not automatically the right hub, and a site should never quietly relocate itself somewhere your policy didn't put it.
Sites never vote.
Hubs federate and decide; sites obey signed assignments and hold no fleet-wide secrets. A box carried out of a building changes nothing anywhere else.
There is no insecure mode.
A site forwards nothing until it is enrolled and approved. No plaintext fallback, no bypass when a certificate fails, no degraded-but-forwarding state to discover later.
3 · What that costs you, measured

Break-then-make has a price and here it is, taken from drills on our lab fleet rather than from a marketing target. Vendors who advertise sub-second failover are describing a WAN path dropping, which ours survives without loss too. These numbers are for losing an entire hub, and this table is the only place on this page they are stated.

Hub lost without warning — site running BGP back online 48 s
Same, site running OSPF 54 s
Planned hub reboot — sites wait it out, no failover at all none
Three sites reconverging after a hub returns < 5 s
Home hub and alternate both unreachable — site holds position and keeps retrying no election

Measured on the lab fleet, FORGE OS 0.9.283, across BGP and OSPF sites. Unplanned-loss figures ranged 33–55 s over repeated runs; we publish the slow end. A planned reboot causes no failover because the hold for a clean hub close outlasts the reboot — sites stay put rather than moving twice.

WAN-emulation validated Field trial: next FIPS 140-3 module (CMVP #5247): today Product certs / STIG mapping: roadmap Runs on your hardware: today

Don't take our word for it. Break it.

Thirty minutes, a live system, and you pick what fails. Watch the honest status and the zero-loss WAN failover for yourself.

Book a live-fire demo
inquiries@hamr-forge.com · hamr-forge.com