Versus runs the same way in both models — the only thing that changes is where it lives, and whether the Versus Collector is optional or required to reach your devices.
Versus ships as the same platform either way — same workflows, same App Builder, same Observe stack, same device drivers. What differs is where the control plane runs and, as a direct consequence, how it reaches your devices.
You install and run Versus inside your own datacenter or VPC. It lives on your network, next to your devices.
Versus runs as multitenant cloud software, hosted and operated by Versus Networks. Your devices stay exactly where they are — behind your firewall.
Every device Versus manages — an F5, a Palo Alto firewall, a NetScaler, a router — needs a network path from wherever Versus is running to wherever that device lives. The Versus Collector exists to provide that path when a direct one doesn't exist, without ever opening an inbound port on your side.
That single fact is what determines whether the collector is optional or mandatory:
Versus installs into your own infrastructure — a VM, a Kubernetes cluster, or bare metal in your datacenter or private cloud VPC. You own the upgrade cadence, the backups, and the network placement.
On-Premises — Customer Network
Optional — segmented VLAN or isolated lab
Everything — Versus, the devices, and (if used) the collector — lives inside your own network boundary. Nothing crosses the internet.
A single on-prem Versus instance usually has one network position — one VLAN, one routing domain. Real enterprise networks rarely are that flat. The collector bridges any gap Versus itself can't route across:
Everything else — the common case — talks to Versus directly, with no agent in the path at all. Where you do deploy a collector, you're not limited to one per site — see Deploy More Than One Collector Per Site below, which applies the same way on-premises as it does for SaaS.
A mid-size enterprise runs Versus on a management VLAN that already routes to every ADC and firewall in their datacenter. Device credentials are added directly in Versus; discovery, workflows, and Observe all talk straight to the devices over their existing management IPs. The collector is never installed — there's nothing for it to do.
The same enterprise acquires a smaller company with its own segmented lab network that corporate security won't route to the main management VLAN. Rather than punching a firewall hole, they drop a single collector binary onto a jump host inside that segment. It enrolls once, opens one outbound connection back to the on-prem Versus instance, and every device in that segment becomes manageable — no inbound rule anywhere.
Versus SaaS is a multitenant, multi-region platform — the control plane, orchestration engine, and Observe stack run in Versus-operated cloud infrastructure, isolated per tenant, with no shared database access between customers. You get a URL, an account, and nothing to patch or back up.
SaaS — Two Separate Networks
Your network
Versus Cloud
Versus never has a network path into your environment. The collector is the only thing that can — and it only ever calls out.
Your ADCs and firewalls are not — and should not be — reachable from the public internet. Versus SaaS has no network path into your environment by design, and that's intentional: it's the same boundary your own security team would insist on. The collector is what makes management possible without weakening that boundary:
Every SaaS customer installs at least one collector as part of onboarding — see Installing the Collector Agent.
A site isn't limited to a single collector — on-premises or SaaS. Enroll two or more collectors against the same site and Versus routes each dispatch to whichever enrolled collector currently has the lowest load; if one collector goes offline, its session simply drops out of consideration and the others keep serving that site's devices without any manual failover step. This is the recommended pattern for any site where losing your only collector would mean losing management access to every device behind it:
"100% uptime" isn't a real SLA — no cloud platform offers it. Versus SaaS is engineered around a more honest and more useful goal: no single point of failure, active-active across regions, and automated recovery for every failure class.
A customer's SaaS tenant is homed in Versus's primary region. That region experiences a disruption while a scheduled firmware-upgrade workflow is mid-flight on a customer's F5 pair. The orchestration engine had already checkpointed after the standby-node upgrade step and before failover — Versus's routing layer shifts the tenant to the shadow region within about two minutes, and the workflow resumes from that checkpoint rather than restarting or leaving the pair half-upgraded. The customer's collector reconnects to the new region automatically over the same static IP it was already allow-listed for — no firewall change required on their end.
A customer's internet circuit drops for four minutes while a certificate deployment is in progress. The collector was mid-way through pushing a renewed certificate to one of three virtual servers. It had already completed and confirmed the first push; the connection drop happens before the second push is acknowledged. Rather than guessing, that step is treated as unknown outcome and reconciled — the collector (once reconnected) or Versus re-checks the actual device state before deciding whether to retry or mark it complete, so the deployment never double-applies or silently skips a server. The third virtual server's push simply waits until the connection is back, then proceeds normally.
| Dimension | On-Premises | SaaS |
|---|---|---|
| Where Versus runs | Your datacenter / VPC | Versus's multi-region cloud |
| Who patches/upgrades Versus | You, on your schedule | Versus Networks, continuously |
| Versus Collector | Optional — only for segmented/isolated networks | Required — the only path to your devices |
| Data residency | Entirely under your control | Regional (e.g. EU tenants can be pinned to Frankfurt) |
| Availability model | Whatever HA you build for your own instance | 99.99% SLA target, active-active multi-region |
| Device network exposure | None beyond your own network | None — collector is outbound-only, devices never internet-facing |
| Best fit | Regulatory/data-residency requirements demanding full control, or a single large site | Fastest time to value, multi-site estates, no infrastructure to run |
| Question | Answer |
|---|---|
| Can I run on-premises and still use the collector everywhere, even where I don't strictly need it? | Yes — some customers standardize on the collector for every site regardless of reachability, purely to keep the firewall posture identical everywhere (outbound-only, no exceptions to reason about site by site). |
| Does SaaS mean my device credentials leave my network? | Credentials are stored encrypted (per-tenant envelope encryption) and are only ever used by the collector inside your own network to authenticate to your own devices — they're never presented to a device from outside your network boundary. |
| What happens to in-flight changes if my internet connection drops during SaaS use? | See Scenario 4 above — orchestrations pause at safe checkpoints and reconcile actual device state on reconnect, rather than assuming success or blindly retrying. |
| Can I self-host and still get the multi-region failover story? | Multi-region active-active is a SaaS-specific operational commitment Versus Networks runs on your behalf. On-premises, that HA design is yours to build — Versus itself has no architectural objection to being deployed multi-region, but you own the infrastructure and the failover drills. |