How It Works
Alta VMS is a control plane on top of Cesbo Alta. Alta ingests and serves the camera streams; Alta VMS manages cameras, users, recordings, and alerts, and proxies video to the browser.
Single binary
Section titled “Single binary”The server is one Go binary with the Vue 3 web UI and the SQLite database engine embedded. The UI is baked in at compile time via //go:embed, so there is nothing else to install — no Node.js, no separate web server, no external database. State lives in a single SQLite file (WAL mode); schema migrations run automatically on startup.
Alta integration
Section titled “Alta integration”Alta VMS talks to each Alta server over REST for camera CRUD and status, and brokers video for the browser:
sequenceDiagram
participant B as Browser
participant V as Alta VMS
participant A as Cesbo Alta
B->>V: Open camera
V->>A: Negotiate stream (signed token)
B-->>A: WHEP (WebRTC) — low latency
Note over B,A: falls back to HLS if WebRTC fails
A-->>B: Live video
Every outbound Alta call is wrapped with retries, a circuit breaker, and a bulkhead limiting concurrency. If an Alta server becomes unreachable, Alta VMS sheds load for that server only and keeps serving the rest — a degraded Alta never takes down the process.
A brief connectivity blip or a fast Alta restart is told apart from a sustained outage: Alta VMS corroborates a suspected failure over two consecutive checks — and, for a restart, against Alta’s reported instance ID and uptime — before taking cameras offline. Blips don’t flap cameras, genuine outages are caught within a few seconds, and a server that flaps repeatedly is reported as down once instead of as a storm of events.
Streaming
Section titled “Streaming”Playback uses WHEP (WebRTC) first for low latency, falling back to HLS automatically. Stream access is authorized with short-lived HS256 JWTs signed per Alta server, so playlist and WebRTC requests can’t be replayed indefinitely.
Background workers
Section titled “Background workers”Work that shouldn’t block requests runs in workers, each of which degrades independently: health_server (Alta server status and config-drift detection), health_camera (camera status), alta_prober (fast availability probing), clips (ffmpeg export), alerts, notifications, reconcile (cleanup of orphaned Alta resources), and cleanup (retention). The enabled set is configurable.
Manual screenshots are initiated from the browser. The old screenshots worker name is invalid; io is withdrawn from the default set and remains opt-in only for compatibility.
Alert and notification delivery is durable: pending deliveries are persisted and retried with backoff, and survive a restart.
The reconcile worker only ever deletes a resource it can prove Alta VMS created — an ownership record written at creation time, not a guess from the resource’s name — so two installations sharing one Alta server can never delete each other’s resources. See Connect an Alta Server for the operator-facing view.
Security
Section titled “Security”- Authentication with JWT sessions; passwords hashed with Argon2id.
- Role-based access control — global admin plus per-group operator/viewer.
- Encryption at rest (AES-256-GCM) for sensitive fields such as Alta credentials, with key rotation support.
- Hardening — strict CSP and HSTS in production, per-user rate limiting, and a dedicated non-login system user when installed as a service.
Observability
Section titled “Observability”The server exposes /healthz, /readyz, and Prometheus /metrics, emits structured JSON logs, and propagates an X-Request-ID across every request and outbound Alta call for end-to-end tracing.