⚠ SpeedFusion Connect (SFC) limits are NOT SpeedFusion limits
SpeedFusion is the bonding & hot-failover engine built into your Peplink device. It is perpetual — there is no subscription on it, and your own device-to-device tunnels (site-to-site, or to your own FusionHub) keep running no matter what.
SpeedFusion Connect (SFC) is Peplink’s public, hosted bonding service — shared bonding endpoints in Peplink’s cloud. Any limit, data quota, expiration date, or renewal notice you see applies to your access to that public SFC service — not to SpeedFusion itself. If an SFC plan lapses, SpeedFusion still works; you only lose the public endpoints.
Part Fifteen: FusionHub, The Cloud Endpoint
The topic
FusionHub is Peplink’s virtual SpeedFusion appliance, SpeedFusion in software, running on a VM instead of in a hardware router. It exists to be the other end of the tunnel when the other end is not a physical site. With FusionHub you establish SpeedFusion connections between cloud servers and physical Peplink devices, which is precisely what a single-site or mobile customer needs to get bonding, smoothing, and FEC, all of which require two endpoints.
How it works on Peplink
You deploy a FusionHub instance in a cloud (it is compatible with all major cloud services) or in your own data center, give it a public IP, and point your Peplink routers’ SpeedFusion profiles at it. It is a fully-featured SpeedFusion endpoint: it supports split tunneling and outbound policy, it can use a public IP to build tunnels and do port forwarding, and it comes in a range of instance sizes including demo versions. Licensing governs how many SpeedFusion peers a given FusionHub can terminate, and performance depends on the CPU, memory, and storage you give the VM, plus the network latency to it.
Why it matters
FusionHub is the answer to “I have one site (or a fleet of vehicles) and nowhere to land the tunnel.” It gives every Peplink deployment a reachable, customer-controlled endpoint in the cloud, which unlocks the entire SpeedFusion feature set for sites that have no second physical location. It is also how you build a hub-and-spoke topology where the hub is a cloud instance rather than a headquarters, ideal when the organization’s center of gravity is the cloud rather than a building, exactly the shift the fundamentals paper’s closing note describes.
Field note
Size the VM honestly, FusionHub performance is bounded by its allocated CPU and memory, and a too-small instance becomes the bottleneck for the whole bonded fleet. Mind the network latency to wherever you host it, since every tunnel rides through it. And track the peer licensing: running out of licensed peers is a common and avoidable surprise as a deployment grows.
From the field — a cloud endpoint for a site with no HQ: A single-site and mobile customer had nowhere to terminate a SpeedFusion tunnel, so the answer was a FusionHub virtual appliance in their cloud. That gave every router a reachable second endpoint, unlocking bonding, smoothing, and FEC for sites that otherwise had only one place to connect.
Part Sixteen: SpeedFusion Connect, The Hosted and Mobile Story
The topic
SpeedFusion Connect (SFC), previously called SpeedFusion Cloud, is Peplink’s hosted infrastructure: a global network of SpeedFusion endpoints you reach from any compatible router, with no extra hardware to buy, set up, or maintain. It gives a single device, or a whole fleet, the full SpeedFusion feature set, bonding, smoothing, supercharged connectivity, by terminating the tunnel on Peplink’s cloud instead of on a FusionHub or second site you run yourself. Around that core sit a few related pieces: the SFC App for app-based setup, SFC Protect for protecting specific applications and connections, SFC Relay for reaching the internet through your own router from elsewhere, and SFC 5G/LTE for on-demand cellular data.
How it works on Peplink
Because the endpoints are Peplink-hosted and globally distributed (across public-cloud regions worldwide), you get fast, well-located egress without standing up any infrastructure: you pick an endpoint, or let one be auto-assigned, and steer the traffic you want protected onto it. The standard way to force a specific application through SFC is an outbound-policy rule, source “any”, the application under protocol, algorithm Enforced, and SFC as the enforced connection. SFC requires firmware 8.1.0 or later and is supported across the Balance, SDX, EPX, HD, Dome, MBX, PDX, BR, Transit, UBR, B One, and SpeedFusion Engine lines.
Commercially it is usage-based, and most customers already have some: every router on an active Care plan includes an annual SFC quota (up to 200 Mbps; throttled to 10 Mbps once the quota is spent, enough to keep Teams, Zoom, Meet, and remote desktop usable). Add-on usage plans run from 500 GB up to 20 TB at 200 Mbps, and an unlimited plan lifts the ceiling to 400 Mbps. Two practical notes: a plan is tied to one device’s serial number, and SFC does not count against a device’s SpeedFusion peer limit, so you can use it freely alongside your own FusionHub or site-to-site tunnels.
 SpeedFusion Connect in practice, each router reaches a Peplink-hosted endpoint over whatever links it has, and gets bonding and protection without any customer-run infrastructure (West Networks Visio library, 2023).
For a fully mobile deployment, vehicles, vessels, pop-up sites, mobile clinics, SFC (or a FusionHub) is how the fundamentals relocate rather than disappear (the pattern the fundamentals paper’s mobile-fleet section describes). Each mobile unit bonds whatever it can see, multiple cellular carriers, plus satellite out of coverage, and tunnels back independently to a consistent hosted endpoint, so the fleet behaves like one network even though every node is moving and changing towers constantly.
Why it matters
SFC lowers the barrier to SpeedFusion from “deploy and manage a FusionHub” to “pick an endpoint and steer traffic to it,” which is exactly right for smaller customers, temporary sites, and mobile users, and because it ships with Care plans, the quota is usually already paid for. SFC 5G/LTE in particular is the easy answer to the recurring single-WAN problem in this paper: the cheapest path to a real second diverse link is often an on-demand cellular plan, which turns a single-WAN site (where smoothing is useless and FEC is limited) into a genuinely resilient two-WAN site where bonding and smoothing finally earn their keep.
Field note
Confirm the device is on firmware 8.1.0+ and has an active Care plan or usage plan before promising SFC, and remember the post-quota throttle to 10 Mbps so a customer is not surprised mid-month. Track usage from the router’s WebUI dashboard. And note the distinction Peter draws in the field: a big on-prem SIM-injector build bonding into a customer’s existing network is SpeedFusion interoperating with an existing network, not SFC, SFC specifically means the Peplink-hosted endpoint, reached from any compatible router with no infrastructure of your own.
From the field — retail 5G backup: A retail chain used SpeedFusion Connect to protect point-of-sale and keep stores online when the wired broadband hiccuped, without standing up any of their own endpoint hardware. Because SFC ships with the Care plan, the protection was largely already paid for.
Part Seventeen: InControl 2, The Management Plane
The topic
InControl 2 (IC2) is Peplink’s cloud management platform, the top layer of the stack from Part One. It is how you configure, monitor, secure, and update Peplink devices, one or a fleet, without logging into individual routers. If SpeedFusion is the engine, InControl is the cockpit for the entire fleet of engines.
How it works on Peplink
InControl organizes devices into organizations and groups, and the distinction is the key to using it well. Organization-level features apply across many groups and are the domain of the central administrator: organization-wide SpeedFusion tunnels (which appear read-only at the group level, so a branch admin cannot alter a compliance-mandated tunnel), pooled eSIM cellular plans shared across all devices, organization-wide SSIDs assigned by tag, grouped-network firewall and outbound policies, global firmware-upgrade rules, and user and license management. Group-level features give granular control within a group: SpeedFusion profile management, Wi-Fi SSIDs with QR codes, radio settings and mesh profiles.
The network configuration you would otherwise do per-router, WAN interface naming and priority, DNS and IP passthrough and health checks, VLANs (with VLAN 1 as the untagged LAN, cloned and tagged for segmentation), outbound policy (including the SaaS and country-based steering that is IC2-only), top-down firewall rules with IDS/DoS and adware blocking, LAN profiles and static routes, OSPF route advertisement, captive portals, CSV-based bulk IP assignment, SNMP/NetFlow/logging, and certificate management, is all done centrally in InControl and pushed down. The Bulk Configurator applies device-specific templates across many devices at once, with administrator overrides where a device needs to differ.
Why it matters
InControl is what makes Peplink scale. Anything you can do to one router you can do to a thousand, consistently, from one screen, and consistency is itself a security and reliability feature: uniform firewall rules, uniform firmware, uniform VLAN policy, fewer places for a mistake to hide. The organization-versus-group split is what lets a central team enforce the non-negotiables (security tunnels, firmware) while delegating the local choices (a site’s Wi-Fi name) to the people who should make them.
Field note
The “Show Advanced Settings” toggle hides a large fraction of the per-WAN and per-sub-tunnel knobs; if a setting you expect is missing, that toggle is usually why. Use group-based templates and cloning to keep sub-tunnel sets consistent across a fleet, and plan multi-sub-tunnel rollouts with change windows and config-drift audits so a partial push does not leave devices inconsistent.
From the field — COVID testing sites, days to hours: Working with West Networks, Peplink helped major US hospitals stand up remote connectivity for COVID testing and vaccination. Sites that traditionally took up to 45 days to deliver came online in hours, because InControl let one team stage and manage every location centrally instead of touching each one.
Part Eighteen: Zero Touch Configuration
The topic
Zero Touch Configuration (ZTC, or ZTP, Zero Touch Provisioning) is the InControl capability that lets a brand-new device configure itself the moment it comes online, with no engineer logging in and no settings typed at the site. You stage the configuration in InControl in advance, ship the device, and when it powers on and reaches the internet it pulls its full config automatically. For a distributed organization, this is the feature that turns deployment from a truck roll into a shipment.
How it works on Peplink
The device’s identity is known to InControl, so when it first connects it is matched to its organization and group and receives everything staged for it: WAN configuration, VLANs and IP assignments, SpeedFusion profiles and sub-tunnels, grouped-network and firewall policies, outbound policy, Wi-Fi SSIDs (often delivered to end users as a QR code), admin credentials, static routes and OSPF advertisement, and more. Because configuration is templated at the organization and group level, a hundred devices come up identically and correctly without a hundred manual setups. Where a device genuinely cannot be onboarded by Zero Touch, InControl still allows manual addition with advanced settings, but the goal is that the common case requires no touch at all.
Why it matters
Zero Touch is where the three benefits of centralized management become concrete: operational efficiency (one engineer stages a fleet instead of visiting each site), error reduction (automated, templated deployment removes the per-site typos that cause most early outages), and consistent security (every device gets the same hardened policy, the same firmware rules, the same firewall posture). For a customer rolling out dozens of branches or a fleet of vehicles, Zero Touch is frequently the single most compelling reason to choose Peplink, the technology is good, but the manageability is what scales.
Field note
The common pitfalls are the same ones flagged throughout this paper, because Zero Touch pushes them at scale: name sub-tunnels by role for clarity, use DWB for mixed WANs, apply smoothing and FEC only on the real-time lanes, and do not enable OSPF on L2 segments. A mistake in a template is a mistake replicated across the whole fleet, so validate a template on one device before pushing it to a hundred.
From the field — zero-touch retail rollout: A retail brand shipped pre-staged Peplink units to each new store; the device powered on, pulled its full config from InControl, and came up with the right VLANs, SpeedFusion, firewall, and a QR-code guest SSID, with no technician on site. Zero Touch is what turns a multi-site rollout from a truck-roll schedule into a shipping schedule.