A Secure Private Cloud on Hardware You Own

A public-safety agency cannot outsource custody of the evidence it is accountable for. The IREX Private Cloud is the layer that makes self-hosting practical: one installable product that turns your servers into a cloud.

What It Is

One Installable Product, Not a Shopping List

The IREX Private Cloud ships container orchestration, software-defined storage, networking, an image registry, identity, a full data plane, and observability as a single product. It deploys on bare metal, virtual machines, private or public cloud, or hybrid infrastructure, and it is operational on three servers in roughly 30 to 60 minutes.

It is hardware-vendor agnostic, installs in air-gapped environments through an auxiliary provisioning server, makes its built-in components fault tolerant through replication, supports zero-downtime rolling upgrades, and scales linearly by adding nodes. Every IREX and Sover deployment includes it.

The whole stack is open source and inspectable: Kubernetes, Ceph, Cassandra, Apache Ignite, Kafka, PostgreSQL, Elasticsearch, and Apache Spark. No third-party proprietary components are required, which is what makes source review and escrow a realistic request rather than a gesture.

Architecture

How One Instance Is Put Together

Two questions decide whether a self-hosted program is buildable: what actually runs inside the instance, and how each camera site reaches it. The answers are separate, and both are yours to set.

One API in Front, Independent Services Behind

A web client, the mobile app and any third-party system reach the platform through one documented REST API over HTTPS. Behind it the work is divided among independent microservices, video analytics, alert dispatching, video search and the rest, which publish to a Kafka event bus instead of calling each other directly. Underneath sits the foundation: Kubernetes runs the containers and migrates them off a failed host on its own, Ceph holds the archive with triple replication, Cassandra holds raw video data and full event records at petabyte scale, and an in-memory metadata store keeps search returning in under a second across petabytes. That structure is why one service can be scaled, restarted or upgraded while the others keep running, and why a single instance is proven in production at 100,000+ cameras, all running real-time analytics with 30-day instant search, with an architectural ceiling of 1,000,000 cameras and 100,000 users reached by adding machines rather than by re-architecting.

See Technology & Architecture
Block diagram of one IREX instance: web, mobile and third-party applications reach the IREX Open API, which fronts video analytics, alert dispatching, video search and other microservices joined by a Kafka event bus, all running over Kubernetes with Ceph and Cassandra underneath

Connect Each Site the Way Its Network Allows

The instance sits in the middle, self-hosted on your own hardware or hosted by IREX if you would rather not run it. A site on fiber or high-availability broadband connects its cameras straight to the cloud with no server on the premises. A site on a constrained or unreliable link takes an IREX edge server instead: analytics and recording happen locally and only events travel up, so the uplink carries a fraction of the traffic and full video moves only when somebody asks for it. That site keeps recording and analyzing through an outage and synchronizes its events when the link returns, and where downtime is unacceptable the edge tier is deployed as redundant servers. Whichever way a camera is attached, users, cameras, modules and updates are managed from one place and the operator sees the same workspace.

See Deployment Models
Diagram of the hybrid architecture: users on the left, the IREX Secure Private Cloud, self-hosted or IREX-hosted, in the center, and two ways in on the right, Option 1 a direct camera connection at standard bandwidth and Option 2 an IREX edge server at reduced bandwidth
The connection is chosen per site, not once for the whole deployment.

What Is Inside

The Layers You Would Otherwise Assemble

  1. Provisioning and Orchestration

    Servers are discovered, powered, tested, imaged and given their roles from one place, so commissioning a rack is a scripted operation rather than a manual install per box. On top of that sits Kubernetes with backup, certificate management, ingress, DNS and networking, and a private image registry.

  2. Storage

    Ceph software-defined storage with an S3 object interface and block devices, plus local volume management for clusters too small to need Ceph. Triple replication and automatic failover are the default posture: when a disk or a node fails, the lost replicas are rebuilt on the survivors with no downtime and no operator intervention, and only speed and free capacity dip until the hardware is replaced.

  3. Data Plane

    Kafka, RabbitMQ, PostgreSQL, MongoDB, Cassandra, Redis, and ClickHouse, all fault tolerant through replication, and all provisioned, scaled and backed up from the console rather than installed by hand.

  4. Observability

    Metrics, dashboards, alerting, and network observability, with centralized logging. This is what the IREX network operations team watches 24/7 under Premier Support, where the customer provides the connectivity for it.

  5. Security and Identity

    Security-event collection from host journals, the Kubernetes audit log and the containers themselves; image vulnerability scanning in the registry, with a severity breakdown per image; and one identity system issuing permissions from full cluster access down to read-only on a single namespace, with single sign-out.

  6. Management Console

    The console is where the platform is operated: nodes, tenants and namespaces, deployments and autoscalers, ingresses and network policies, scheduled backups and restores, audit logs filtered by component and namespace, and provisioning for every database and broker above. Command-line access to the cluster is issued through the same identity system, so nobody hand-builds a certificate.

What It Buys You

The Four Sovereignty Guarantees

  • 100% customer ownership and control of data. IREX neither owns nor accesses customer video, events, logs, alarms, watchlists, or floor plans. There is no IREX-side data plane for customer media: an architectural fact, not a contractual promise.
  • 100% on-premises or private-network deployment available. On-premises, private cloud, or fully air-gapped, with no internet dependency at runtime. IREX-hosted SaaS is an opt-in convenience, never a requirement.
  • 100% of the source code auditable. The infrastructure stack is entirely open source, and IREX-authored components are available for source review or escrow under license.
  • 100% of user actions auditable. Every high-risk AI action is bound to a mandatory Case ID and written to an append-only, tamper-evident log, exported daily.

The Trust Boundary

One Boundary, and You Define It

What You Control, and What IREX Cannot Reach

Cameras, sensors and uploaded media, the edge servers, the Private Cloud itself with its analytics, archive, search index and audit log, and the operators, analysts and integrations that reach them over your own network: all of it sits inside one boundary you define. IREX sits outside. Support, updates and engineering access exist only where you grant them by agreement, and there is no data plane for customer media at all, which is what turns the guarantees above from a promise into a property of the architecture. The public internet, third-party services and unsolicited external requests stay outside too. Nothing crosses except by your decision, and an air-gapped deployment removes the crossing entirely.

Read the Data Sovereignty Guide
Diagram of the customer-controlled trust boundary: cameras, sensors and uploaded media, edge servers, the IREX Private Cloud holding analytics, archive, search index and audit log, and operators and integrations, all inside one dashed boundary, with IREX support and updates outside it reaching in only by agreement and with no data plane for customer media, and the public internet and third-party services outside

Operating It

What It Takes to Run One

Smallest Footprint
Operational on three servers in roughly 30 to 60 minutes, plus 35 to 60 minutes to stand up the auxiliary provisioning server where one is used.
Growth
More cameras means adding Kubernetes and Ceph machines; a deeper archive means adding Ceph machines; more users means adding balancer machines. The platform takes up the new capacity by itself.
Upgrades
Zero-downtime rolling upgrades, applied strictly in sequence with no skipping. LTS upgrades are mandatory, and each LTS is supported for at least 18 months.
Sizing
Produced by IREX engineering from four inputs: camera count with approximate bitrates, the mix of analytics modules, the retention period for video and events, and the maximum size of the person and vehicle databases.

FAQ

Can it run with no internet connection at all?

Yes. Fully air-gapped installation is supported through an auxiliary provisioning server, and the platform has no internet dependency at runtime.

What is the smallest viable footprint?

The platform is operational on three servers in roughly 30 to 60 minutes, then scales linearly by adding nodes. Sizing for a given camera count, retention period, and AI workload is calculated per project.

Do upgrades take the system down?

The infrastructure layer supports zero-downtime rolling upgrades of containerization components, node operating systems, and system services, provided the cluster has reserve compute capacity. Upgrades are applied strictly in sequence and cannot be skipped, only stable versions are permitted as targets, LTS versions are mandatory, and each LTS is supported for at least 18 months.

Who operates it day to day?

IREX normally deploys and operates the infrastructure layer, and training is available for a customer who wants to run it without us. Whoever does needs Linux (Debian or Ubuntu), networking, configuration-management and basic Kubernetes skills, and works mostly through the management console rather than the command line. Continuous monitoring by the IREX network operations team covers IREX-hosted deployments and customer-hosted deployments under Premier Support, not every deployment by default, and it depends on the customer providing connectivity to the site. A customer-hosted instance sets and operates its own backup and recovery under a documented shared-responsibility matrix, with IREX supplying the guidance and the tooling.

What can IREX reach inside our deployment?

Only what you grant by agreement, and only for support, updates and engineering access. There is no IREX-side data plane for customer media, so in a customer-hosted deployment IREX holds none of the following: live or recorded video, events, detections, matches and their snapshots, watchlists and the person and vehicle databases behind them, maps, floor plans and camera positions, the audit log including Case ID records, or user accounts, roles and permission structures. Because there is no copy, your retention policy is the only retention policy, and a legal request served on IREX cannot produce your video.

Are we locked into your hardware?

No. The platform is hardware-vendor agnostic and installs on bare metal, virtual machines, private or public cloud, or hybrid infrastructure. There is no proprietary appliance: every node is a standard, commercially available server, and the CPU and GPU mix is sized against the servers you already own.

Bring Your Own Iron

Send us the server inventory and the camera count and we will come back with a capacity model rather than a brochure.