Ayonix Video Analytics

Deployment architecture

On-premise deployment: your servers, your network, your data

In short

On-premise deployment runs analytics on customer-owned servers inside the customer network, typically alongside an existing VMS. It suits sites where cameras already aggregate locally and where data control, rather than bandwidth, is the deciding requirement. Ayonix publishes on-premise deployment as a first-party capability.

Who this suits

  • Sites where cameras already aggregate into a local VMS or recording estate
  • Organisations whose policy requires processing on owned infrastructure
  • Deployments with many cameras in one location, where central processing is efficient
  • Environments with existing server capacity, virtualisation and operations practice
  • Sites that need analytics and VMS to sit in the same operational domain
Manager reviewing factory, retail, transit and parking sites in an operations centre
Conceptual illustration of multi-site operational oversight. AI-generated conceptual image, not a customer deployment.

Architecture

How it is put together

  • Cameras stream to the local network; analytics servers consume streams directly or via VMS re-stream.
  • Detection, tracking and rule evaluation run on customer servers inside the customer network.
  • Events are delivered to the local VMS, operator queues or internal systems.
  • Aggregate series are published to internal dashboards and BI tools.
  • Administration, user management and audit logging run within the same environment.
On-premise video analytics architecture diagram

Characteristics

What this model means in operation

The properties below are what actually differentiate the deployment models from each other.

Bandwidth
Camera-to-server traffic stays on the LAN, which is normally well provisioned. No continuous video crosses the internet. WAN use is limited to whatever central or multi-site reporting is configured.
Latency
Low and predictable within the site. Detection to VMS alarm involves only local network hops, so operator alerting is prompt without depending on an external service.
Privacy
Video and events remain on customer-controlled infrastructure throughout. This is frequently the model that satisfies procurement and information-governance requirements with the least negotiation.
Resilience
Depends on the customer’s own server and network resilience. Analytics inherits whatever redundancy the site already operates, which in mature environments is considerable.
Central management
Managed within the customer environment using existing operations tooling. Multi-site estates can federate reporting while keeping processing local to each site.
Software updates
Applied on the customer’s change-management schedule. Nothing updates without the customer initiating it, which is often a requirement in regulated environments.
Health monitoring
Stream availability, decode errors, processing headroom and rule status are exposed for collection by the customer’s existing monitoring platform rather than requiring a separate tool.
Logging
Structured logs with request identifiers, written into the customer logging estate. Media never appears in logs and personal data is redacted.
Backup
Configuration, rules and operational records are backed up under the customer’s existing backup regime, which usually means no new process is needed.
High availability
Achieved through the customer’s standard approach — clustering, virtualisation-level failover or redundant nodes with camera-group failover. Design follows existing site practice.
Scaling
Scales by adding server capacity within the site. Because processing is centralised, adding cameras is usually a capacity question rather than a per-location hardware decision.

Planning

Sizing inputs, cost and limitations

Hardware sizing inputs

  • Total camera streams, resolution and codec
  • Analysis frame rate per camera for the intended rules
  • Concurrent rule count and complexity per camera
  • Whether streams come direct from cameras or via VMS re-stream
  • Retention period for event evidence and aggregate series
  • Available server capacity, virtualisation platform and any accelerator hardware

Sizing is done against your actual stream profiles and rule set by Ayonix. No channel-count or throughput figure is published on this site, because none has been supplied.

Cost considerations

  • Server capacity, either new hardware or headroom in existing infrastructure
  • Data-centre or comms-room power, cooling and rack space
  • Internal operations effort for patching, monitoring and backup
  • No recurring per-stream cloud processing cost
  • Hardware refresh cycle aligned to existing server lifecycle policy

Limitations

  • Requires available server capacity and operations capability, which not every site has.
  • Camera-to-server LAN traffic can be substantial where cameras are high-resolution and numerous.
  • A site-wide failure affects all analytics at that site, unlike the distributed edge model.
  • Multi-site estates need a federation design; on-premise alone does not provide cross-site management.

Frequently asked questions

Can analytics run on our existing virtualisation platform?

Frequently yes, subject to sizing and to whether the workload needs accelerator hardware that the platform can present to a guest. This is determined during architecture review against your actual stream profiles rather than assumed either way.

Should analytics consume cameras directly or via the VMS?

Both are supported. Via the VMS avoids a second connection to each camera and can simplify credentials; direct avoids depending on VMS availability. The decision usually follows existing network design and camera ownership.

Does anything phone home?

On-premise deployment is designed to operate within the customer network. Where any outbound connectivity is proposed — for licensing or support — it is stated explicitly in the architecture review and can be removed, which is what the air-gapped model formalises.

Compare with other models

Author
Gabriel Bamola, Chief Marketing Officer, Ayonix
Technical review
Dr Sadi Vural, Founder and Chief Executive Officer, Ayonix
Published
Last reviewed

Get an architecture review for your estate

Site count, connectivity, data-residency constraints and whether alerting must survive an outage decide the model. An architecture review works through those with you and produces the sizing inputs Ayonix needs.

Request an architecture review Compare all deployment models