On-premise
On-premise face recognition
Run recognition on servers you own, in a room you control, with a data lifecycle you can show an auditor — and no dependency on a link you do not control.
- Face images and templates stay on site
- Latency is a LAN hop, not an internet round trip
- Capital purchase rather than a per-transaction meter
- Retention and audit on systems you already run
In short
On-premise face recognition runs matching on servers inside the customer's own network, so face images and biometric templates never leave the premises. It removes internet round-trip latency and recurring per-transaction cost, and puts retention, access control and audit under systems the customer already operates.
On-premise is not a philosophical preference. It is what you choose when a specific constraint has already removed the alternatives — a regulator, a contract, a latency budget, or a network link that cannot be relied on at the moment it matters most.
This page therefore concentrates on the things that actually make an on-premise deployment succeed or fail: sizing it honestly, segmenting the network properly, enforcing retention in software, and naming who operates it before it goes live.
Why organisations move recognition on site
Rarely because on-premise is fashionable. Usually because a specific constraint made the alternative impossible, and the constraint came from a regulator, a contract or a network.
Biometric information cannot lawfully or contractually leave the premises.
Capture, template creation, matching and storage all happen inside the customer’s network. There is no egress path to disable because there is no egress path.
Cloud latency makes a door feel broken even when it works.
A LAN hop replaces an internet round trip. The perceptible delay between presenting a face and a door opening is the difference between a system people like and one they resent.
The site’s internet connection is unreliable, and a failed link means a queue.
Nothing in the decision path crosses the wide-area link, so a link outage is a reporting problem rather than an access problem.
Recurring cloud processing cost grows with usage and never stops.
On-premise is a capital purchase with a known maintenance cost, which is a different financial shape and one that many public-sector budgets are built around.
Regulatory or contractual restrictions prohibit third-party processing.
No third party processes anything. The processor is the customer, which simplifies the assessment rather than mitigating it.
Substantial investment already exists in local cameras and server capacity.
Recognition joins the existing estate rather than replacing it, using the cameras, the network and often the racks that are already there.
The organisation must be able to demonstrate the full data lifecycle.
Storage location, retention period, access log and deletion all run on systems the customer already audits, so the evidence is in a form the auditor already accepts.
How it works
Camera to business system, entirely inside your network
Every arrow in this flow stays within the customer’s own infrastructure. That property is the reason to choose this architecture, and it is worth being explicit about where it holds.
-
Camera to server
Analysed streams reach the recognition server over the local network, on a segment chosen for this traffic.
Fails when: Analysed streams share a VLAN with general office traffic and contend with it at exactly the busiest hour.
-
Detect, assess, match
Detection, quality assessment and comparison run on the local server against a gallery stored locally.
Fails when: Hardware is sized for average load, and the peak — shift change, flight arrival, match day — is where it fails.
-
Decide and dispatch
The result reaches the door controller, the VMS, the operator interface or the business application over the same local network.
Fails when: The integration endpoint is on a segment the recognition server cannot reach, discovered at commissioning.
-
Record and retain
Events, evidence and audit entries are written to local storage under the customer’s own retention and backup regime.
Fails when: Retention is configured as a policy document rather than in the software, so it is never actually applied.
Architecture
Everything inside the perimeter
The value of this design is a property rather than a feature: no biometric data crosses the boundary. That is worth diagramming precisely.
Capture
Existing camera estate-
IP cameras
ONVIF or RTSP, on a dedicated segment
-
Gate and door terminals
Where a terminal is the capture point
-
Customer applications
Submitting images via the local API
Recognition
Customer-owned servers-
Detection and quality
Rejects unusable captures
-
Matching engine
1:1, 1:N and watchlist
-
Template store
Encrypted at rest, on site
Action and record
Existing business systems-
Door and gate controllers
Receive the open command
-
Video management system
Receives events and alarms
-
Audit and reporting store
Customer retention and backup regime
Every element is inside the customer’s network. The only traffic crossing the perimeter is whatever the customer chooses to allow for licensing, updates or reporting — and in an air-gapped variant, none at all.
Operations
The controls an on-premise deployment has to carry
Choosing on-premise moves these responsibilities to the customer. That is the trade, and it is worth making explicitly rather than discovering later.
Encryption
Templates encrypted at rest and streams and API traffic encrypted in transit, with keys managed by whatever the organisation already uses for its other secrets rather than by a second, parallel system.
Role-based access control
Enrol, search, export, configure, change a threshold and read the audit log are separate permissions. Collapsing them into one administrator role removes the distinction an audit depends on.
Audit logging
Every comparison, configuration change, export and access to the audit record itself, with the identity of the person responsible and a retention period that outlives the staff involved.
Backup and restore
Gallery, configuration and audit store all backed up — and restored during commissioning. A backup that has never been restored is an assumption rather than a control.
High availability
More than one node with a replicated gallery, where the operational cost of downtime justifies roughly doubling the hardware. For many deployments it does not, and saying so is more useful than selling it.
Network segmentation
Biometric traffic on its own segment, with explicit rules for what may reach it and what it may reach. This is usually the first thing an auditor asks about and the easiest to get right at design time.
Sizing
The deployment sizing questionnaire
Sixteen questions. Answer them and an architecture review can produce a hardware profile; answer fewer and any figure is a guess. There are deliberately no performance numbers on this page, because a number without these answers describes somebody else’s deployment.
Cameras and capture
- How many camera streams will be analysed continuously, and how many only on demand?
- What resolution and frame rate does each analysed stream deliver, and is that negotiable?
- At each capture point, how many pixels span the face where people actually pass?
- How many people pass each analysed camera in the busiest hour of a normal week?
Matching workload
- Is the workload 1:1 verification, 1:N identification, watchlist matching, or a mixture?
- How many identities are enrolled today, and what is the expected figure in three years?
- How many comparisons per second must the system sustain at peak, not on average?
- What is the acceptable time from capture to decision at each point — a door, a gate, an alert?
Availability and operations
- What happens operationally if the service is unavailable for an hour? For a day?
- Is high availability required, and is that active-active or a warm standby?
- Who operates the servers, and what are their existing backup and patching regimes?
- What is the maintenance window, and how often may the system be taken down?
Data lifecycle and governance
- How long must captured images be retained, and what deletes them?
- How long must templates persist after a person’s entitlement ends?
- How long must audit records be kept, and who will eventually inspect them?
- Which network segment will hold the biometric data, and what may reach it?
Honest comparison
When on-premise is the wrong answer
A page that only lists advantages is a brochure. These are the conditions under which a different architecture is genuinely better.
| Architecture | Strongest when | Give up | If the link drops |
|---|---|---|---|
| Cloud service | Volume is low or bursty, latency tolerance is generous, and there is no restriction on where biometric data may be processed. | Face images or templates leave the premises, which some legal bases and most contracts do not allow | Recognition stops until connectivity returns. |
| On-premise server | Biometric data cannot leave the site, the camera estate is concentrated, and there is an operations team to run it. | Hardware must be specified, bought and maintained | Unaffected — the cameras, the server and the doors are all on the same network. |
| Edge appliance | Sites are many and small, bandwidth is expensive or unreliable, and decisions must be local. | Capacity per box is finite; more cameras means more boxes | Recognition and local actions continue; events queue and forward when the link returns. |
| Edge plus central server | A multi-site estate needs both local autonomy and one governed identity record. | Two tiers to operate, version and secure rather than one | Sites keep recognising against their last synchronised gallery; changes reconcile on reconnection. |
| Air-gapped | The environment is classified, sovereign, or contractually prohibited from external connectivity. | No remote support; every intervention is on site | There is no link. This is the design, not a failure mode. |
Where sites are many, small and scattered with no server room and no local hands, edge or hybrid beats on-premise. Where volume is low and there is no residency constraint, a cloud service may genuinely be the cheaper and simpler answer.
On-premise, edge and fully air-gapped deployment
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
ONVIF and RTSP camera input
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Protocol support. Whether a specific camera produces usable results depends on measured pixels across the face at the capture point, not on protocol compatibility.
On-premise readiness checklist
Everything below has to be answered before hardware can be specified. A supplier who quotes without them is guessing, and the guess will be wrong in the direction that suits them.
-
Count the streams that will be analysed continuously
Not the number of cameras on site. Continuous analysis and on-demand analysis are different workloads, and the split determines the hardware more than the total does.
-
State the gallery size now and in three years
1:N workload scales with the gallery. Sizing for today’s figure guarantees a re-procurement at exactly the point the system has become load-bearing.
-
Define the latency budget at each decision point
A door, a gate and a control-room alert have different tolerances. One number for the whole system will be too strict somewhere and too loose elsewhere.
-
Plan the network segment for biometric traffic
Which VLAN, what reaches it, what it may reach, and how that is enforced. Biometric data on the general office segment is an avoidable finding in the first audit.
-
Decide the availability requirement honestly
High availability doubles hardware and adds operational complexity. It is right for a border checkpoint and usually wrong for a staff canteen door.
-
Assign operational ownership before go-live
Who patches, who monitors, who restores from backup and who is called at 03:00. An on-premise system without a named owner degrades quietly.
-
Set retention per data category in software
Captured images, templates, event records and audit entries have different appropriate lifetimes. Enforce each in configuration, and log deletion.
-
Design encryption at rest and in transit
Templates encrypted at rest, streams and API traffic encrypted in transit, and keys managed by whatever the organisation already uses for its other secrets.
-
Map roles to the permissions that actually exist
Enrol, search, export, configure, change a threshold and read the audit log are separate permissions. Granting them as one administrator role removes the distinction the audit depends on.
-
Rehearse restore, not just backup
A backup that has never been restored is an assumption. Restore the gallery and the audit store during commissioning, while there is still time for it to fail safely.
Frequently asked questions
What hardware does on-premise face recognition need?
It depends on the number of continuously analysed streams, the gallery size, the matching mode and the latency budget — and no honest figure can be given without those. This page includes a sizing questionnaire that collects exactly what an architecture review needs. A vendor quoting a server specification before seeing those answers is quoting for a different deployment.
How many cameras can one server handle?
There is no portable answer, and any number quoted without context is marketing. Throughput depends on stream resolution and frame rate, how many faces appear per frame, the gallery size being searched, whether liveness is enabled, and the hardware. The useful approach is to measure the actual streams during a pilot and size from that measurement, which is what an architecture review produces.
Does on-premise mean no internet connection at all?
No — that is air-gapped, which is a further step. On-premise means recognition and biometric storage happen inside the customer’s network; the site may still have an internet connection for other purposes, and the system may still reach a licence server or an update repository if the customer permits it. Where no external route at all is permitted, air-gapped deployment is supported and is described on the deployments page.
How is high availability achieved?
By running more than one recognition node with the gallery replicated between them and traffic distributed by whatever the organisation already uses for load balancing. Whether that is worth its cost is a business decision rather than a technical one: it roughly doubles the hardware and adds operational complexity, which is right for a checkpoint that cannot stop and usually wrong for an office side entrance.
What happens to face images after a match?
Whatever the configured retention says, and the defensible default is to discard the captured image once the match resolves. Templates persist only while the person’s entitlement lasts. Both periods should be enforced in the software rather than in a policy document, and deletion should be logged — a retention claim that cannot be demonstrated is not a control.
Can on-premise and edge be combined?
Yes, and for a multi-site estate that combination is usually the right answer. Edge devices handle capture and matching locally at each site, while a central on-premise server holds the authoritative gallery, the policy set and the consolidated audit record. Sites keep working while disconnected and reconcile when the link returns. This is described as the hybrid model on the deployments page.
How does this compare to a cloud face recognition API on cost?
They are different financial shapes rather than different amounts. Cloud is operational expenditure that scales with transactions and never ends; on-premise is capital expenditure with a known maintenance cost. Which is cheaper depends entirely on volume and time horizon, and the honest comparison requires both the transaction forecast and the amortisation period. Neither is universally cheaper, and a vendor claiming otherwise is selling what it happens to have.
Who is responsible for security patching?
The customer, since the servers are theirs — which is the point of the architecture and also its main operational cost. The system should fit the organisation’s existing patching, monitoring and backup regimes rather than requiring new ones, and the operational owner should be named before go-live rather than discovered afterwards.
Related
Where to go next
Deployment comparison
Cloud, on-premise, edge, hybrid and air-gapped, with what each gives up.
Edge face recognition
When many small sites beat one large server.
Border control
Multi-site topology where connectivity cannot be assumed.
Security
How this site is secured, and what it does and does not log.
Privacy and governance
Retention, access logging and template protection as design work.
Face recognition API
Calling the on-premise deployment from your own applications.
Next step
Request an architecture review
Answer the sizing questionnaire on this page and the review comes back with a hardware profile, a network design and the retention configuration — not a price list. If the honest answer is that a different architecture fits better, that is what you get told.