Nexa Sight
Face recognition and access authorization on the cameras you already have
The problem
Sites with a dozen cameras still put one guard in front of a wall of screens. Badge systems tell you a credential went through a door, not who was carrying it, and not whether that person then walked into a zone they were never cleared for.
When something goes wrong, finding it means scrubbing footage by hand, and the answer arrives hours after it mattered.
What we built
A real-time recognition and authorization layer that sits on top of the cameras a site already has. It identifies enrolled people live and checks permission at two levels: per camera, and per polygon zone the operator draws directly onto the video feed.
Time-of-day schedules layer on top of that, so a contractor cleared for the loading bay on weekday mornings is a violation on Sunday night. Every face is colour-coded as it moves: green for authorized, red for unauthorized or inside a restricted zone, orange for a face that is not enrolled at all.
People are enrolled from several photos or from an uploaded video with frames extracted automatically. Everything lands in a searchable log with filtering, PDF export, presence timelines and per-camera activity reports.
How it is built
Application
- FastAPI
- PostgreSQL
- Next.js 16
- React 19
- TypeScript
- Tailwind v4
Vision models
- InsightFace buffalo_l
- SCRFD-10GF detector
- ArcFace ResNet-50 embedder
Vision runtime
- ONNX Runtime
- TensorRT FP16 to CUDA to CPU fallback chain
- OpenCV with hardware H.264 decode
- Shapely for zone polygons
Built as part of the Nexa Suite platform between January and July 2026: roughly six months of active development, 61 commits across 151 tracked files, by a team of three to four engineers.
Engineering decisions that mattered
Inference decoupled from display
Detection runs at about 10 frames per second per camera while video streams to the browser at 30. Operators see smooth video and the GPU does the expensive work a third as often.
Detection and embedding merged into one model pass
The version this replaced ran the model twice per frame, once to find faces and once per cropped face to identify it. Merging them halved GPU work per frame.
Permission rules cached rather than re-queried
Zone and permission rules used to be read from the database on every frame, around 360 queries a minute per camera. Ten-second in-memory caches took that to roughly six.
Hardware video decode
Hardware H.264 decode took frame decode from 30 to 40 milliseconds down to about 2 at 2304x1296. That is the difference between keeping up with a 30 fps camera and falling behind it.
Idle cameras cost almost nothing
Detection load drops to roughly 3 fps when no face has been seen for three seconds, so an empty corridor is nearly free.
How it is sold
Our own product, built in house and sold as a multi-tenant SaaS platform, with an on-premise edge deployment for sites whose cameras cannot leave the local network.
Common questions
- Does Nexa Sight need new cameras?
- No. It is a software layer over existing camera infrastructure and works with standard H.264 IP camera streams. The usual constraint is GPU capacity for the number of concurrent cameras rather than the cameras themselves.
- Can it restrict access by area rather than just by door?
- Yes, and that is the main difference from a badge system. An operator draws polygon zones directly onto the live video feed, and permissions are checked per zone as well as per camera, with time-of-day schedules on top. Someone cleared for one area is flagged the moment they appear in another.
- Can it run without sending video off site?
- Yes. Alongside the multi-tenant SaaS there is an on-premise edge deployment for sites whose footage cannot leave the local network, which is a common requirement in defence, critical infrastructure and some manufacturing environments.
Guides on Nexa Sight
What to work out before you buy one.
