Skip to content

Configuration model

Brokerr intentionally keeps bootstrap configuration small. config.yml selects the database, data directory, and master-key source. Runtime configuration lives in SQLite and is edited through the authenticated UI or /api/v2 resource API.

Data Location Examples
Bootstrap config.yml SQLite path, data directory, master key file
Source instance SQLite Plex server URL, duplicate strategy, identity
Target instance SQLite account identity, score format, HTTP policy
Credentials encrypted SQLite rows access tokens, refresh handles, Plex token
Profile profile tables scope, features, webhook/scheduler enablement, revision
Runtime state synchronization state tables baseline, fingerprints, pending operations, ignores
Audit/history run and diff tables operations, logs, Apply/Revert outcomes
Managed lists list binding tables bindings, members, unmatched, list-specific ignores

Source and target deletion is blocked while a profile references the instance. Profiles with active managed-list bindings must detach those bindings before deletion.

Source, target, and profile updates use row revisions. A stale editor receives HTTP 409 rather than overwriting a newer change. Run history records the profile lifecycle instance, so deleting and recreating the same public ID does not make old logs or fingerprints belong to the new profile.

API responses never return secret values. They report only which credential keys exist. The encryption key is supplied by bootstrap and credentials are authenticated-encrypted before SQLite storage. See Security and storage.