For managed service providers
Every network you're on the hook for, on one screen.
The board sorts your whole book of business so you know which client to open first. Devices, gateways, incidents and changes roll up per customer, and each client's device credentials stay encrypted on a gateway inside their network. Not yours, and not ours.
No credit card, and every client you carry lives under one organization.
One console
Every client's devices, gateways, incidents and changes in one place, not one browser tab per vendor dashboard.
Triaged for you
The board is ordered worst-first by a rule you can read, so the client having the worst morning is at the top.
Isolated per client
Per-client gateways, overlapping IP ranges, and credentials that never leave the client's own network.
You're the network team for a dozen networks you didn't design.
RMM covers the endpoints. PSA covers the tickets. The switches, APs and firewalls at forty sites are covered by a folder of bookmarks, four vendor cloud dashboards, and whoever remembers that site.
Nobody notices drift
A VLAN added by hand two years ago, firmware nobody's tracking, a spanning-tree root that moved. It isn't a ticket until it's an outage, and then it's an outage at a site nobody has opened since install.
The client calls first
Per-vendor dashboards each know about their own gear at one site. None of them can tell you which of your clients is in trouble right now, so the escalation path starts with your phone ringing.
Every network is bespoke
Whatever the client bought, inherited, or had installed by the last guy. Standardising on one vendor's cloud isn't an option when you don't own the purchase order.
The portfolio dashboard
A board that tells you where to start
Turn on MSP mode and Customers becomes a top-level section of the console. It opens on the whole book: how many clients need attention, how many devices you're carrying and how many can't be reached, gateways online out of gateways deployed, and every open incident across every client, worst severity first.
Need attention
3
1 critical
Customers
28
across 41 sites
Devices
614
7 unreachable
Gateways
40/41
online
Open incidents
9
1 critical · 5 warning
Illustrative numbers. Health is always shown as an icon and a word, never colour alone.
How worst-first is decided
Customers sort by health, then by the severity of their worst open incident, then by how many they have, then by how much of the fleet is unreachable, then by name. Severity outranks count because one critical is a worse morning than three low ones, and sorting by count would bury it. The last key makes the order total, so a refresh can never reshuffle the board under your cursor.
- health
- worst severity
- incident count
- devices unreachable
- name
And "needs attention" says why
A client is flagged by named rules, and the verdict is the worst rule that fired, never a later check quietly downgrading an earlier critical. Every flag carries its reason onto the card, so triage doesn't start with opening the customer to find out what's wrong.
Lifecycle is an input, because "nothing set up yet" means something different for a prospect than for a client you've billed for a year.
- No gateways configured — the client has sites but nothing that can poll them.
- Devices unreachable — as a share of the fleet, warning then critical.
- Gateways offline — a gateway that was phoning home has stopped. Some offline is a warning; all offline is critical, because nothing is reaching that client at all.
- Gateway never checked in — shipped, never phoned home. Someone never plugged it in.
- Devices found, none under management — discovery worked, onboarding stalled.
- Failing collectors — the device answers, but something we poll it for keeps erroring. Monitored badly, which is easier to miss than not monitored at all.
- Nothing provisioned — an active customer with no sites, gateways or devices at all.
The customer record
A real record for every client
Each customer gets a page: their sites, their gateways and when each last checked in, their open incidents, their runbook, and every state number rolled up from the same source the dashboard reads, so the board and the page can't tell you two different stories.
- Lifecycle
- Prospect → onboarding → active → suspended → offboarded, so a half-installed prospect isn't flagged like a live client. Rename the states or drop the ones you don't use; the editor only offers the states your organization actually has.
- Tier and account manager
- Bronze/silver/gold out of the box, or whatever you sell. Filter the whole board by tier or lifecycle when you want to look at just the gold accounts, or just the ones still onboarding.
- A runbook, not a CRM
- Free-form notes per customer: who to call, the maintenance window, the odd thing about their core switch, links out to the ticket, the wiki, the contract. It links to your systems of record instead of copying them, because a stale copy of your PSA is worse than none.
- Quick actions where you are
- Jump into the client's context, issue a provisioning token for a new site, invite their admin, suspend. Anything you can't do right now is disabled, with the reason shown.
Onboarding
New client to monitored network, same afternoon
Onboarding a client takes one form and one gateway.
-
01
Type the client's name
One submit creates the customer, their first site, their access boundary and their admin team, and mints the provisioning token, in a single transaction, so you never end up with half a client.
-
02
Deploy the gateway
Appliance, VM, or a container on something already at the site. It takes the token, dials out, and needs no inbound port, no VPN and no firewall change on the client's side.
-
03
Watch it fill in
Discovery is passive first. It listens for LLDP/CDP, DHCP and mDNS, so onboarding a client's network doesn't set off the IDS you're also being paid to respect. Devices, links and topology populate themselves.
Already have clients in here?
Existing divisions convert in bulk. The picker ranks the likely candidates (it can tell which ones came in through the onboarding flow) and you confirm. Nothing is designated a paying customer on a guess, so your internal IT division never turns up on the board as a client. If a conversion partly fails, it tells you which ones and why, by name.
Multi-tenancy
One console. Networks that never touch each other.
Every client runs their own gateway on their own network. The console federates the view; it never becomes a shared path between two customers.
Clients A and B both run 10.0.0.0/24. That's fine. Each is reached through its own gateway, so overlapping address space is a non-event instead of a re-addressing project you have to sell.
Their credentials, on their side
You never build a vault of forty clients' enable passwords in someone else's cloud. A credential is relayed to that client's gateway and encrypted there, with the key sealed to a TPM, split with the cloud, or kept in a local file, as you choose per gateway. We don't store their passwords in our cloud.
How that works, in detail →Commercial roles aren't infrastructure roles
Reading the customer book is its own permission, separate from the one that manages sites and devices. An account manager can see the portfolio without touching a switch, and a field engineer with full infrastructure rights doesn't get your book of business.
Give the client a view, scoped to them
Invite a client's own admin straight from their page. They land in a team scoped to their network and nobody else's, in the same console you use. You decide what they can see and change.
Redundancy per site
Deploy a second gateway at a site that matters and management work spreads across both, with standby takeover. One dead VM at a client isn't a blind spot you find out about during an outage.
Change management
The discipline you'd want if it were your network
The riskiest thing an MSP does is change a client's config at 9pm on a Tuesday. Every change here is planned, approved, snapshotted before it touches anything, verified after, and reversible.
Approvals, including theirs
Multi-level approval, so a change can wait on your senior engineer and on the client's sign-off before it goes anywhere near the gear.
Maintenance windows
Schedule into the window you agreed with that client, and let it run without anyone staying up to press the button.
Snapshot and roll back
The device's config is captured before the change and restored if it misbehaves. "We can put it back" is a sentence you can say to a client and mean.
An audit trail you can hand over
Who changed what, when, on whose approval, with the diff. Useful in a post-incident review, and useful when a client asks what you've been doing.
It works across the gear your clients actually own: Cisco, Juniper, Arista, UniFi, Netgear, EdgeRouter and more, over standards like LLDP/CDP, SNMP and SSH rather than one vendor's API. When something does break, the faults the platform knows come with a named cause and a fix: an unexpected spanning-tree root, a duplex mismatch, a guard violation. It's a focused set today, and growing.
Coming soon
What we're building next
The MSP side of the product is where most of our attention goes. Here's what's next, and if your practice needs one of these sooner than the others, tell us and it moves up.
Next up
Which endpoint is eating the bandwidth
Data transfer per endpoint, tracked across switch ports and access points. "The internet is slow at the Denver office" turns into a named device on a known port with a number next to it, and you don't need a span port, probe or flow collector at every site. You already know where every endpoint is attached; this adds how much traffic it's moving.
A client portal in your name
White-label the client-facing side with your own branding and domain, showing each client the slice of their network you choose. The scoped access underneath already works; what's coming is making it look like yours.
Client-ready reporting, on a schedule
Monthly network health, inventory, incidents and the changes you made, generated per client and sent without anyone assembling it by hand. It's the document that justifies the retainer, built from data you're already collecting.
Ticketing that goes both ways
An incident here will open a ticket in the system your techs already live in, and close it when the network recovers. Until then, the customer runbook links out to your tools.
Alerts that fix themselves
For faults with a known remedy, you'll get a proposed change ready for one-click approval, built on the same audited, reversible change machinery you use by hand. That means fewer 2am calls that only ever needed one command.
Listed here rather than above, because nothing on this page's feature list is a plan. If one of these is the thing that would make us a fit, tell us. Early MSPs shape what we build first.
One plan for the whole book
One organization, one bill, however many clients you carry. The MSP plan is $899 a month and includes 400 monitored devices and 100 client networks, with 120 gateways and 100 team members. There's no per-client minimum, and taking on client number 101 costs $2.99 a month, not a new contract.
Most network tools are shaped for one company with a few big sites: lots of devices, very few separate networks. Your book is the opposite: every client is a network of its own, and most of them are small. So the MSP plan trades device headroom for a hundred client networks at a per-network rate sized for how MSPs actually grow.
Past the included 400, devices are $0.51 a month each, up to 4,000. Annual billing is $8,990, ten months for twelve. The plan is self-serve; the call is there if you want help sizing it or onboarding your first clients.
Talk to a human
We'll walk through the product on one of your real client sites. Bring a messy one.
Talk to us about your book →Or skip us entirely: sign up and pick the MSP plan yourself. The offer stands either way.
MSP questions worth asking
Does every client need their own account? +
No. You have one organization and each client is a customer inside it, with their own sites, gateways, devices and access boundary. You sign in once and every client is on the same board, so there's no tab-switching between tenants to answer "who's down right now".
Two of my clients use the same IP range. Problem? +
No. Each client's devices are reached through that client's own gateway, so identical address space in ten different networks never collides. Overlapping ranges were a design assumption, not a workaround.
Do you store my clients' device passwords? +
No. They're relayed to the gateway on that client's network and kept encrypted there. We don't store them in our cloud, so a breach of us is not a breach of forty of your clients. You can verify it by running the self-hosted edition and watching the traffic.
Can a client see their own network without seeing anyone else's? +
Yes. Invite their admin from their customer page and they land in a team scoped to their network only, with the permissions you grant, and access is checked per request against the scope they're acting in. Today that's our console with our branding; a portal in your own name is what we're building next.
Does this replace my PSA or RMM? +
No, and it shouldn't. This is the network layer your RMM doesn't cover: switches, APs, firewalls, config and topology. Your PSA stays the system of record for the relationship; the customer runbook links out to it rather than copying it, and two-way ticketing is on the roadmap.
What happens when I lose a client? +
Mark them offboarded, or remove the designation, which is non-destructive, so if they come back their history and settings are still there. There's no agent buried in their config, and the client can be handed their gateway and carry on.
Bring your messiest client site
The one you inherited, with the switch nobody has logged into since 2021. Point a gateway at it and see what comes back. That's a better evaluation than any demo we could give you.
Want to kick the tires with nothing sent to us first? Run it yourself →