Connect an Alta Server
Alta VMS manages cameras through one or more Cesbo Alta media servers. Add at least one before adding cameras.
Add a server
Section titled “Add a server”Go to Settings → Connections and click Add server. Provide:
- Name — a label for the server.
- Base URL — the Alta server’s address, e.g.
http://192.168.0.10. - Admin credentials — the Alta admin user and password.
- Callback base URL — the address the Alta server uses to reach Alta VMS for WebRTC (WHEP) authorization, e.g.
http://192.168.0.10:3303orhttps://vms.example.com.
Credentials and stream-token secrets are encrypted at rest (AES-256-GCM). Alta VMS verifies the connection on save.
If adding a server fails partway through, resources already provisioned on Alta are rolled back automatically. An hourly background sweep also cleans up resources left behind by a crash mid-operation or a failed teardown — but only resources this installation can prove it created: every resource Alta VMS provisions is recorded in an ownership ledger, and only a confirmed entry ever authorizes the sweep to delete it. A resource’s name is never enough on its own, so if two Alta VMS installations happen to point at the same physical Alta server, neither can ever delete the other’s cameras’ streaming resources. Every deletion is recorded in the audit log.
One consequence of proving ownership rather than guessing from a name: a resource that was already orphaned before this safeguard was in place carries no ownership record and is never auto-deleted. If you have leftover resources from before an upgrade, clear them by hand from the config drift view’s On Alta, not in VMS list.
Server health
Section titled “Server health”Each server is health-checked continuously. A server can be healthy, unavailable (connectivity lost), or in config drift (its configuration no longer matches what Alta VMS expects). When a server goes unavailable, its cameras show as offline and the affected workers shed load for that server only — other servers keep running.
Alta VMS probes each server for availability about once a second, refreshes status and telemetry roughly every 15 seconds, and runs the heavier config-drift scan roughly every 5 minutes. Camera status is polled every few seconds. Servers are probed concurrently, so one slow or unreachable server never delays the checks for the rest. All four intervals are adjustable on Settings → Connections:
- Camera health interval — 1–30 seconds, default
3. - Server ping interval — 1–10 seconds, default
1. Sets how fast outages and restarts are detected. - Server status — 10–300 seconds, default
15. Host/storage telemetry, plus the reachability corroboration and clean-poll debounce that clears a flapping server. It does not set how fast an outage is detected. - Server config — 60–3600 seconds, default
300. The heavier config-drift scan — how often Alta VMS re-fetches the server’s full configuration to check it against what’s expected. Kept on its own, slower cadence so it never competes with outage detection.
Blips, restarts, and outages
Section titled “Blips, restarts, and outages”Alta VMS tells a brief hiccup apart from a real outage before it reacts, so a one- or two-second network blip or a fast Alta restart no longer flaps every camera on the server offline:
- Connectivity blip — the server was briefly unreachable and came straight back, and Alta VMS confirmed the Alta process did not restart. Cameras keep their status; the incident is recorded as an info-level event.
- Restart — the server was briefly unreachable and Alta VMS confirmed the Alta process actually restarted (its instance ID or uptime changed). Live streams drop while it comes back; recorded as a warning-level event.
- Unavailable — the server stays unreachable. This is caught within a few seconds; its cameras go offline and load is shed for that server only, while other servers keep running.
A camera only flips offline for a whole-server problem after two consecutive failed checks, so a single caught blip leaves no offline/online flicker in its history. A server that flaps repeatedly — three transient outages within five minutes — is reported as unavailable once, instead of a stream of restart events. When the server recovers, its cameras come back together rather than each reconnecting on its own.
These server-level events appear in the Events list and, for admins, the alert bell — see Alerts & Notifications.
Inspect config drift
Section titled “Inspect config drift”When a server is in config drift, its Config drift badge on Settings → Connections is clickable. Click it to open a report comparing what Alta VMS expects against what the server currently reports. The comparison runs on demand — when the dialog opens and on Re-check — and is read-only: inspecting drift never changes the server’s health state. Secret values are never displayed, only whether they’re present or missing.
The report is grouped into up to four sections, and only groups with something to show appear:
- Configuration — server-level settings that diverged: the authorizer, storage bindings, the VOD access setting, or the WebRTC callback path. Each item shows Our value against On Alta. Most have an Apply to Alta button that writes the stored value straight to the server in one click; a few are database-integrity issues that can only be fixed by editing the server, so they offer Edit server instead. The VOD playlist path is a special case: you can adopt whatever Alta currently reports, or reset it to the default
vod. - Cameras missing on Alta — a camera whose receiver or channel doesn’t exist on Alta anymore gets a Restore button that recreates it from Alta VMS’s stored settings (expand the card to preview exactly what will be created first). A camera whose receiver and channel both exist but some field — source, name, storage, or enabled state — has diverged is shown for comparison only; resolve it by editing the camera in Alta VMS, since these can’t be pushed to Alta directly. When more than one camera is restorable, a Restore all button handles them together.
- On Alta, not in VMS — resources present on the Alta server with no matching camera or storage in Alta VMS. See below.
- Ignored — resources you’ve told Alta VMS to leave alone (collapsed by default). Each has a Stop ignoring button that puts it back into scope.
When more than one item across the Configuration and Cameras groups can be fixed safely, a Fix all safe button applies all of them in one action.
Resources on Alta with no VMS record
Section titled “Resources on Alta with no VMS record”The On Alta, not in VMS group lists resources Alta reports that no camera or storage in Alta VMS references. Each row carries one of two badges, or none:
- auto-cleanup pending — Alta VMS created this resource and has a record of doing so; the reconcile sweep will remove it automatically once it’s been unreferenced past the grace period.
- VMS-shaped, not ours — named the way Alta VMS names its resources, but with no record of Alta VMS creating it. Usually a leftover from before the ownership ledger existed, or a sign that another Alta VMS installation shares this Alta server.
- (no badge) — a resource that doesn’t look like anything Alta VMS would have created.
Three actions are available per resource:
- Import to VMS — offered on camera-ingest resources (receivers). Adopts it as a new, disabled camera; finish setting its credentials under Cameras before enabling it. Import all does this for every importable resource at once.
- Ignore — leaves the resource on Alta untouched, but removes it from this list permanently and protects it from the reconcile sweep. Use this for a resource you know belongs to something else.
- Delete from Alta — permanently deletes the resource from the Alta server. This is the only way to clear a resource that predates the ownership ledger and will never be auto-swept — it’s an explicit, audited, one-at-a-time action, and it’s refused if any Alta VMS record still references the resource.
Server telemetry
Section titled “Server telemetry”When a server reports runtime telemetry, its row on Settings → Connections gains an expand arrow. Click it to reveal a recent snapshot of the Alta host:
- CPU — current usage, core count, and the 1-minute load average.
- Memory — memory used of total, with the percentage.
- Uptime — time since the Alta process last started, plus the running Alta version.
- Storage — one usage bar per recording volume, showing percent used and free space of total.
The footer shows the Alta instance ID and how long ago the reading was taken. Values refresh in the background — this is a recent snapshot, not a live stream — and are not stored, so they reappear after an Alta VMS restart once each server is polled again. A storage bar turns amber at 75% full and red at 90%; CPU and memory are informational and aren’t color-coded.
Multiple servers
Section titled “Multiple servers”Add as many servers as you need. Cameras, groups, maps, and the video wall span all of them; each camera remembers which server it belongs to.