The Platform
ForgeVis records video on its own. The platform is what you add when one recorder stops being enough — a database instead of config files, a web interface instead of SSH, and clusters instead of servers you keep track of by hand.
It is an addition, not a dependency. Nothing below changes how the recorder works; it changes who tells it what to record.
Three shapes, and how to tell which one you need
The deciding question is not the number of cameras. It is where the camera list lives — and each answer brings the next piece with it.
| Cameras defined in | Needs a database | Needs the platform | |
|---|---|---|---|
| Standalone | config.yaml | no | no |
| Standalone + database | cameras table | yes | yes — the schema is its |
| Cluster | cameras table, assignment by consensus | yes | yes |
Standalone
One server, cameras in the configuration file, changes picked up by the file watcher. This is the whole product for a single site, and it needs nothing on this page — the guide covers it end to end.
Standalone with a database
The camera list moves out of the file and into PostgreSQL. The recorder reads the cameras whose node_name matches its own and picks up changes through a notification trigger.
This is where the platform becomes necessary, and for a reason worth stating plainly: the recorder does not own that schema. It reads two tables and creates neither. Something has to build them, keep them migrated and give you a way to edit rows that is not psql — and that something is the backend.
Cluster
Several recorders hold one shared state through Raft consensus and decide between themselves which node records which camera. A failed node's cameras move to healthy ones without anyone being paged.
Here the recorder loads all enabled cameras and records only the ones the cluster assigned to it. It follows that a cluster node with no cluster is not a standalone server — with no membership there is no assignment, and a node with no assignment records nothing. Turning cluster.enabled on is not a setting you can leave half-applied.
What each part does
Backend
The API and the owner of the database.
- Owns the schema. Tables, indexes and migrations are its, including the two tables the recorder reads. Migrations run before recorders start — see Shared database.
- Objects, cameras, tenants, licences.
- Talks to the nodes. Health, metrics, cluster membership, certificates.
- Issues cluster certificates. Each cluster gets its own authority; the backend keeps the private key encrypted and signs what the nodes request. See Adding nodes.
Control Plane
The operator's interface — the fleet, and the clusters built out of it.
Adding a server, forming a cluster, promoting a node to voter, draining one before maintenance: all of it here, none of it over SSH.
Shipped scope
Overview and Fleet are complete and enabled. Objects, cameras, tenants, licences, billing, branding and the audit log exist in the code but are turned off — a module becomes visible when every part of it does what the interface promises. Until the licence module is on, a licence is installed by hand: drop forgevis.lic next to config.yaml on the node.
What this does not change
The recorder keeps working the way it always did.
- Video never passes through the platform. RTSP, HLS and WebRTC are served by the node, straight to the client. The platform is a control path, not a data path — losing it costs you the interface, not the recording.
- A node keeps its own authentication. The platform authenticates to a node as a machine user from that node's
security.users, the same mechanism an operator uses. - No transcoding appears anywhere. H.264 and H.265 are passed through, as before.
Where to go next
- Shared database — who owns the schema, and the order things must start in.
- Adding nodes — credentials, certificates, and forming a cluster.
- Clustering & HA — the recorder side of the same subject.