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, Fleet, objects, cameras, tenants, licences and the audit log are on. Billing and branding exist in the code but are turned off — a module becomes visible when every part of it does what the interface promises. A licence is added under Licences and assigned to a cluster or a server.

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.
The platform transcodes nothing. Video goes from the node straight to the client. The 720p step, when a viewer picks it, is encoded by the node itself.