In a high-stakes environment, a standard dashboard can be an operational liability. InControl2 is an excellent engineering tool, and precisely because it shows everything, it shows too much to the people who need one answer under pressure: is the network healthy, and if not, what do I do. Custom management portals exist to close that gap between engineering telemetry and operational decisions.
What a custom portal is, and is not
A custom portal is a bespoke software layer that sits on top of the Peplink estate and presents each operational role exactly the view it needs. It does not replace InControl2; it refines it. The captain sees which links are active and whether a data cap is approaching, without the logs. The broadcast operator sees bonded link stability during a live transmission, with a degrading cellular path flagged before it matters. The site manager at branch forty sees red or green and a phone number. The network engineer keeps the full InControl2 depth underneath, untouched.
The need is real because generic monitoring tools interpret SpeedFusion poorly: they report a link as up while missing the loss and latency behaviour that actually threatens a bond. Translating that nuance into operational language is the whole job.
How the integration works
InControl2 is the data engine. Our portals interrogate its API for real-time telemetry, link health, signal, throughput, GPS, consumption, and render it into role-specific views, alerts and reports. The architectural principle that keeps this safe is strict separation: the presentation layer reads; the network's routing and bonding logic runs entirely on the Peplink layer, unaffected by anything the portal does. If the portal disappeared tomorrow, the network would not notice. That one-way dependency is what makes a bespoke layer appropriate for mission-critical estates, and its absence is what makes deeper integrations risky.
The same API path lets network data flow outward into systems that already exist: fleet software, vessel management, enterprise monitoring, client reporting. Often the right portal is not a new screen at all, but network intelligence appearing inside the tool the operation already lives in.
When bespoke beats off-the-shelf
Honest guidance, because bespoke software is not always the answer: if your team is technical and small, InControl2 alone is probably enough, and we will say so. A portal earns its keep in three situations. When non-technical people carry operational responsibility for connectivity, crew, site managers, production staff, and need decisions rather than data. When you provide managed connectivity to clients and need branded, comprehensible reporting that builds trust without exposing your whole management plane. And when network status must appear inside existing operational systems rather than in yet another browser tab. Outside those cases, spend the money on engineering instead.
Design principles that matter
The portals that survive contact with operations share a few properties. Role-first design: each audience gets its own view, built from the question that role actually asks. Decisions over data: an alert should carry what to do next, not just what happened. Honest simplicity: a red/green summary must be backed by drill-down for the engineer who arrives to fix the red. Alert discipline: a portal that cries wolf gets ignored, so thresholds are tuned to page a human only when a human decision is needed. And resilience of the portal itself: read-only API access, no credentials stored that could touch configuration, and graceful degradation if the data source blinks.
How we build them
We start with the roles and the questions, not the screens: who looks at this, under what pressure, needing which decision. From that comes a thin first version, real telemetry, the core view, in front of real users quickly, then iteration on what the operation actually asks of it. We build on the InControl2 API with the read-only separation described above, brand it as yours where client-facing, and document it so it can be maintained without us. Portal work usually rides alongside a wider deployment or managed service; the network engineering and the visibility layer are better designed together.
The short version
Keep InControl2 as the engineering truth, add a read-only presentation layer that turns telemetry into role-specific decisions, apply real alert discipline, and only build bespoke where the operational case is genuine. If your people are drowning in dashboards, or your clients deserve better reporting than a screenshot, get in touch for a scoping conversation.
Frequently asked questions
Does a custom portal replace InControl2?
No. InControl2 remains the management plane and the data source; the portal is a read-only presentation layer on top. Engineers keep full InControl2 access throughout.
Can the portal control the network?
Ours deliberately do not, in mission-critical estates. Read-only separation means the visibility layer can never cause the outage it exists to help you avoid. Where controlled actions are genuinely needed, they are scoped narrowly and audited.
Can it feed our existing systems instead of being a new screen?
Yes, and that is often the better design: network telemetry delivered into fleet, vessel or enterprise monitoring systems via API rather than another destination to check.
Is this only for large fleets?
Scale matters less than audience. A single vessel with a non-technical crew has a stronger case than a fifty-site estate run by a capable network team.
What does it cost to maintain?
Designed properly, little: the heavy machinery is InControl2, which Peplink maintains. The portal layer is deliberately thin, documented, and built so your own team or any competent developer can sustain it.