Most engineers treat InControl2 as a convenience. I treat a badly planned InControl deployment as a single point of failure waiting for its moment, because I have seen what happens when a fleet loses local access to a remote router or when configuration drift turns a routine update into a recovery job. This is how we structure InControl2 so it scales without ever locking you out of your own hardware.
What InControl2 is, and what it is not
InControl2 is the management plane, not the data plane. It pushes configuration, aggregates telemetry and gives you a fleet-wide view; the router itself keeps forwarding packets whether or not it can reach the cloud. That separation matters: losing the InControl connection degrades your visibility, not your traffic. It also provides a secure remote path to each device's local web admin, which is what makes off-site diagnosis practical for maritime and remote installations.
Two onboarding prerequisites catch people out. InControl2 is included while a device is under warranty; out-of-warranty units need a subscription, so check serials early. And the device must be able to reach the InControl servers, which means UDP 5246 and TCP 443 outbound; a strict upstream firewall that blocks those leaves devices unable to check in.
Structure the hierarchy before you add a single device
The most consequential decisions happen before any hardware is enrolled. The hierarchy has three tiers: Organisations, Groups and Tags. Create a new Organisation only when you need hard administrative or data isolation, separate clients, say; everything else belongs in Groups, which inherit organisation-level policy.
The instinct is to group by geography. I recommend grouping by role or policy instead: a change intended for all mobile endpoints should never be able to touch a stationary gateway just because they share a postcode. Tags then do the fine-grained work, and they are functional, not decorative; a tag can push a VLAN, an SSID or a firewall rule to a subset of a Group. Adopt a strict naming convention early, something like [Role]-[Type]-[ID], because with a few hundred endpoints the difference between a confident mass update and a nervous one is knowing exactly which devices a tag touches.
The local-versus-cloud conflict
Every Peplink engineer eventually meets the banner: "This configuration is being managed by InControl." It is not a warning, it is a statement of authority. Force a local change underneath it and the cloud will overwrite your work on the next sync; that is where configuration drift comes from.
My rules here are simple. The cloud is the source of truth: push changes through InControl, and audit by comparing the device's running config against the applied config in the cloud. But always keep the local door open: the Device Web Admin toggle stays enabled in our deployments, because if the WAN fails and the router cannot reach InControl, local access is your only way in. Relying solely on the cloud to reach hardware is a risk I will not take on a mission-critical network. Local overrides are for emergencies; everything else goes through the plane.
Credentials follow the same logic. Centralise administrator passwords through InControl so no forgotten local accounts linger, keep access logging on across the organisation for the audit trail, and remember that a remote password push will get you back into a device you have been locked out of.
Orchestrating SpeedFusion and firmware
The VPN Configurator is where central management earns its keep. Building point-to-point or hub-and-spoke SpeedFusion topologies by hand is error-prone and does not scale; through InControl you pick hubs and spokes, the platform handles key exchange and routing, and you define per-WAN bonding and failover priorities so critical traffic rides the most resilient links. Tunnel health and latency are then visible fleet-wide in real time.
Firmware discipline is the other half. Never push a new release fleet-wide on day one. We test on a canary device in live conditions first, schedule the wider rollout for low-traffic windows, and keep the rollback path ready. Stability beats novelty on a production network, every time.
When DIY stops scaling
A self-managed InControl setup is fine for a lab or a single site. Somewhere between ten devices and a few hundred, the cost of a misconfiguration changes category, and that is usually when we get the call. We architect the management plane, document it, and train the internal team to run it; for clients who want more, we use the InControl API to feed telemetry into bespoke portals, plain-English status for non-technical stakeholders, GPS and link health integrated into their own operational tools. The goal is always the same: move from reactive troubleshooting to an environment where every change is planned, validated and reversible.
The short version
Group by role, not geography. Let tags do the precision work. Keep the cloud authoritative but never surrender local access. Canary every firmware release. Do those four things and InControl2 becomes what it should be: the reason your fleet is boring to operate. If you are planning a deployment beyond a handful of devices, get in touch for a brief scoping conversation.
Frequently asked questions
Does the network go down if InControl2 is unreachable?
No. The data plane is local to the router; traffic keeps flowing on the last applied configuration. You lose central visibility and the ability to push changes until connectivity returns.
Is InControl2 free?
It is included for devices under warranty. Out-of-warranty hardware needs a subscription, which is worth checking before you plan a rollout around older units.
Should I group devices by site or by role?
By role or policy. Geographic grouping feels natural but leads to policy changes hitting devices that merely share a location. Use tags for anything finer-grained.
What ports does a device need to reach InControl2?
Outbound UDP 5246 and TCP 443. Devices behind firewalls that block those cannot check in or receive configuration.
How do I stop local changes being overwritten?
You mostly should not; the overwrite is the management plane doing its job. Push changes through InControl so the cloud stays the source of truth, and reserve local overrides for genuine emergencies with the Device Web Admin toggle enabled as your safety net.