Ayonix Video Analytics

Deployment architecture

Air-gapped deployment: no outbound connectivity at all

In short

Air-gapped deployment runs analytics entirely inside an isolated network with no outbound connectivity. Licensing, updates and support artefacts move through a controlled offline process. Ayonix states that its systems are built to run fully air-gapped in addition to on-premise and edge deployment.

Who this suits

  • Defence, government and national-security environments
  • Utility and industrial operational-technology networks isolated from corporate IT
  • Regulated sites where outbound connectivity is prohibited by the security programme
  • Organisations whose data classification prevents any external transfer
  • Sites where a supply-chain assurance requirement rules out live external dependencies
CCTV-protected perimeter fence line of a modern industrial facility at dusk
Conceptual illustration of a monitored industrial perimeter. AI-generated conceptual image, not a customer deployment.

Architecture

How it is put together

  • Cameras, analytics nodes and the VMS all sit inside the isolated network boundary.
  • Detection, rules, evidence creation and audit logging run entirely within the boundary.
  • No component initiates or requires an outbound connection during normal operation.
  • Licensing and software updates are transferred through the site’s controlled media process.
  • Diagnostics are exported through the same controlled process when support is required.
Air-gapped 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
No external bandwidth is used at all. Internal traffic follows the same pattern as on-premise or edge deployment depending on where processing sits within the boundary.
Latency
Determined entirely by the internal network. There is no external dependency that could introduce variable latency.
Privacy
The strongest available position. No video, event, metric or telemetry leaves the boundary under any circumstances, which is typically the requirement that makes this model mandatory rather than preferable.
Resilience
No external dependency means no external failure mode. Resilience is entirely a function of the internal design, which the operator controls completely.
Central management
Management operates within the boundary. Where an estate spans several isolated networks, each is managed independently and reporting is consolidated through the site’s existing controlled process.
Software updates
Delivered as signed artefacts through the controlled media process, verified before installation and applied on the site’s change schedule. Update cadence is typically slower and more deliberate than connected deployments, which is expected.
Health monitoring
Health is collected and displayed within the boundary. No telemetry is transmitted externally, so monitoring integrates with the operator’s internal platform rather than a vendor service.
Logging
Immutable local audit logging of events, operator actions, evidence access and configuration changes. This record is usually central to the regulatory case for the deployment and is designed in from the outset.
Backup
Performed within the boundary under the site’s existing backup and media-handling procedures, including any classification-driven handling requirements.
High availability
Achieved with redundant nodes inside the boundary. Because external dependencies are absent, availability design is unusually predictable.
Scaling
Scales within the boundary by adding capacity. Growth planning must account for the controlled process required to introduce any new hardware or software.

Planning

Sizing inputs, cost and limitations

Hardware sizing inputs

  • Camera count, resolution and analysis frame rate inside the boundary
  • Rule count and complexity per camera
  • Local evidence and audit retention requirements, which are often longer in regulated environments
  • Redundancy requirements set by the security programme
  • Physical and environmental constraints of the secure facility
  • Change-control cadence, which affects how capacity headroom should be planned

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

  • Hardware and redundancy inside the boundary, typically specified conservatively
  • Controlled-process overhead for every update and support interaction
  • Longer change cycles, which favour provisioning headroom over frequent expansion
  • No recurring external service cost of any kind
  • Assurance and accreditation effort, which is often the largest non-hardware cost

Limitations

  • Updates are slower by design, because every artefact passes through a controlled process.
  • Remote support is not possible; diagnostics must be exported through the controlled process.
  • Any capability that genuinely requires external connectivity is unavailable and should be identified early.
  • Introducing new hardware or software takes longer than in connected environments.

Frequently asked questions

Does anything need to reach the internet?

No. Air-gapped deployment is designed so that no component initiates or requires an outbound connection during normal operation. Licensing and updates move through the site’s controlled media process instead.

How are updates handled?

As signed artefacts transferred through the controlled process, verified before installation and applied on the site change schedule. The cadence is slower than connected deployments, which is a deliberate property of the model rather than a limitation to work around.

What audit evidence is produced?

Events, operator assessments, evidence access and configuration changes are logged immutably inside the boundary. That record is usually what makes the deployment acceptable to the regulator or accreditor, so it is scoped at the start rather than added later.

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