On-premise
Runs where your systems run
Deployed on your own infrastructure rather than reached as a service over the internet, so privileged traffic stays inside your estate.
Runs on your infrastructure. Managed from one control plane.
OmniPriv deploys on-premise across VMware, Red Hat and OpenStack as a hardware-agnostic software appliance, on the infrastructure you already run.
High availability, tenant isolation, disaster recovery and break-glass access are handled by the platform itself, so the operational questions are answered by the product rather than by a professional services engagement.
Deployment · your infrastructure Health checks passing
A single appliance for one site
Software appliancehardware-agnostic
Same product at every sizeillustrative
- platform families: VMware, Red Hat and OpenStack
- 3platform families: VMware, Red Hat and OpenStack
- topologies: standalone, active-standby or full HA cluster
- 3topologies: standalone, active-standby or full HA cluster
- supported browsers, plus a full command-line CLI
- 4supported browsers, plus a full command-line CLI
- inbound ports to open on managed target systems
- 0inbound ports to open on managed target systems
Four decisions this makes for you
The deployment model is part of the security argument. These are the choices OmniPriv makes so you do not have to.
Software appliance
Hardware-agnostic by design
Delivered as a software appliance, so it is not tied to a particular vendor's iron or to a specific hypervisor generation.
Unified administration
One console, one repository
A single administration UI over one central credential repository, rather than a separate console for every function.
Browser and CLI
Reachable the way you work
Full control from Edge, Chrome, Firefox or Safari, or from the command line for teams that automate everything.
High availability, without a second product
Availability is a property of the deployment rather than an add-on. OmniPriv clusters across nodes with health checking and replication built in, so the platform survives losing a node the same way your other critical systems do.
- Multi-node clustering with container-based health checks and automatic restart
- Heartbeat monitoring between nodes, so a stalled node is noticed rather than waited on
- Database replication and load balancing across the cluster
- Granular disaster recovery, credentials restored without restoring the entire system
- Offline device management, credentials for devices that rarely reach the corporate network stay managed and current
Cluster · 3 nodesillustrative
node-1
healthy
node-2
healthy
node-3
healthy
Load balancer · traffic share
All nodes healthy · heartbeat steady
Tenants and emergency access
Remote sites, subsidiaries and the worst day of the year each need an answer that does not undermine the rest of the model.
Offline device management
Credentials for devices that rarely reach the corporate network stay managed and current, rather than drifting out of the vault.
Strict multi-tenancy
Isolation via org_id on every resource with schema-per-tenant data separation and per-organization RBAC, including dedicated ROOT, DEFAULT and SYSTEM organizations.
Break-glass, still recorded
A built-in procedure to bypass the platform in a genuine emergency, available when you need it, and fully written to the audit trail when you use it.
Secondary security password
An additional mandatory layer in front of password vault access, so reaching stored credentials takes more than an authenticated session.
Organizations · isolation by org_idillustrative
ROOTDEFAULTSYSTEM
- Subsidiary Aschema tenant_aown RBAC
- Subsidiary Bschema tenant_bown RBAC
- MSP customerschema tenant_cown RBAC
Password Vaultsecondary password required
Field laptopback online · credential current
Break-glass used in audit trail
Platform specifications
The deployment facts, stated plainly. Nothing here depends on a particular hypervisor.
- Deployment Model
- On-Premise (VMware, Red Hat, OpenStack / OpenSource platforms)
- Interface
- Browser Web GUI (Edge, Chrome, Firefox, Safari) + Command-Line CLI
- Mobile Client
- Built-in mobile browser client with TOTP 2FA and ticket approvals
- High Availability
- Multi-node clustering, container health checks, heartbeat monitoring & DB replication
- Multi-Tenancy
- Strict org_id isolation per resource (schema-per-tenant), ROOT/DEFAULT/SYSTEM orgs
- Encryption
- All sensitive data encrypted at rest and in transit
- Supported Protocols
- SSH, RDP, VNC, HTTP, Database (Native DB clients via transparent proxy)
- Approval Principle
- 4-Eyes principle (minimum 2 independent approvers, no self-approval)
- AI & Threat Analytics
- AI keystroke dynamics anomaly detection & real-time behavioral analytics
- Disaster Recovery
- Break-glass emergency procedure + granular credential restore without full system restore
Deploy it on hardware you already own
- Your infrastructure
- Your keys
- Your topology
OmniPriv runs on-premise as a software appliance, with clustering and disaster recovery built in.
We will walk through the topology that suits your estate, standalone, active-standby or a full HA cluster.
Frequently Asked Questions
Have a question that is not here?
Talk to the OmniPriv team about your identities, systems and AI agents.
Request a DemoOn-premise across VMware, Red Hat and OpenStack or other OpenSource-based platforms, as well as in private or public cloud. It supports standalone, active-standby and full high-availability cluster topologies, so the same product covers a single site and a distributed one.
No. Privileged connections are brokered through the platform rather than intercepted at the machine, so an inbound port does not have to be opened on the target system.
OmniPriv clusters across multiple nodes with container-based health checks and automatic restart, heartbeat monitoring between nodes, database replication and load balancing. A node that stops responding is detected and worked around rather than waited on.
There is a built-in break-glass procedure for exactly that emergency. It lets administrators bypass the platform to reach a system, and every use is written to the audit trail, so the exception is available without becoming an invisible bypass.
Yes. Isolation is enforced via org_id on every resource with schema-per-tenant data separation, and each organization gets its own RBAC. The model includes dedicated ROOT, DEFAULT and SYSTEM organizations, which is what makes it workable for MSPs as well as for enterprises with subsidiaries.
