Sentinel architecture overview
Services, data flows and security architecture of Sentinel v8.0.
On this page
Sentinel v8.0 runs as a set of Docker services on a single Ubuntu GPU server. Browsers connect over HTTPS to an nginx front end, which serves the web console, forwards API calls to the Go API gateway and proxies live video from MediaMTX.
Services
| Service | Role |
|---|---|
| nginx | TLS termination, static web console, API and HLS proxy |
| API gateway (Go) | Authentication (JWT), REST endpoints, WebSocket event stream, audit logging, licence verification |
| MediaMTX | RTSP ingest from cameras, HLS output, recording |
| AI inference | GPU object detection (YOLO) |
| Face recognition / face search | Enrolment, search and matching |
| Person tracker | Cross-camera re-identification |
| Event intelligence | Behaviour analysis and anomaly detection |
| VMS connector | ONVIF discovery and VMS integration |
| Alert service | Email and webhook notifications |
| Report engine | Automated reports |
| Ollama | Local LLM for the VedaAI assistant |
Data stores
PostgreSQL holds users, cameras, events, cases, watchlists, recordings metadata, evidence, ANPR reads, reports, settings and audit logs. Redis stores refresh tokens, rate-limit counters and sessions; Kafka carries events between services; Milvus stores face embeddings at scale; MinIO stores images and evidence files.
Data flows
- Live video: camera (RTSP) → MediaMTX → HLS segments → nginx (HTTPS) → browser player.
- AI events: video frames → AI inference → Kafka → event intelligence → API gateway → database and WebSocket broadcast → operator event feed.
Security
- TLS 1.2 / 1.3 at the front end
- JWT access tokens with short expiry and refresh tokens held in Redis
- bcrypt password hashing; initial passwords must be changed at first sign-in
- Role-based access; audit log of write operations
- Per-IP rate limiting and WAF rules