Deployment security requirements
C21 Live Control holds the values that let it broadcast on your behalf. Protecting them is a shared job: the product encrypts its backups and does not echo stored credentials back through the API or the assistant; the host that runs the product has to be protected by whoever deploys it. This page lists what the deployment must guarantee before production credentials go into Live Control.
What Live Control stores that is sensitive
Live Control stores these values as it uses them, not encrypted field by field: the encoder sends the stream key to the provider, not a hash of it. That is why the protection applies to the host as a whole rather than to each value.
| Item | What it contains |
|---|---|
| Configuration database | Stream keys of destinations (YouTube, Twitch and the other RTMP providers), credentials of object storage destinations (S3, Azure Blob Storage), Remote Folders (NFS, WebDAV) and Target Folders (FTP, SFTP, S3), SRT passphrases of Channels and destinations, encryption keys and DRM provider credentials, and integration keys. |
| Backups | A dump of that database plus the installation configuration, encrypted. Everything the database holds is in every backup. |
| Installation configuration | Service passwords, the key that encrypts the backups, the initial credentials and the TLS private key. They live under the installation directory on the host, readable by root only. |
Anyone who can read the host's disk, the installation directory or a backup together with its key can broadcast on your channels and reach your storage. Treat the host as a sensitive asset.
Requirements
The deployment must meet all four. The installer checks none of them: they are decisions about the host, taken before Live Control is installed.
Disk encryption on the host
Encrypt the volumes that hold the installation directory, the data volumes and the backup directory: LUKS on a bare-metal or virtual host, or the volume encryption of your cloud provider (encrypted EBS volumes, Azure disk encryption and the like). Encryption at rest is what protects the database when a disk, a snapshot or a decommissioned machine leaves your control. Enable it before the installer runs: the installer does not encrypt the disk.
Host access restricted to administrators
Only the people who administer the platform log in to the host, each with their own account and an SSH key: no password login and no shared account. Anyone with root on the host can read the database and the backup key, so host access is equivalent to holding every stream key. Keep the list of host administrators as short as the list of System Administrators in Live Control.
The database is not exposed outside the host
The installer keeps the database on the stack's internal Docker network and does not publish its port. Do not publish the database port, do not point remote database clients at it and do not open it to other hosts for reporting. Everything that needs the data reaches it through the Live Control API. Remember that ports published by Docker are not filtered by ufw (see Prepare the host).
Off-host copies of backups stay encrypted and restricted
Backups are encrypted on the host with a key that lives in the installation configuration. If you copy them elsewhere (an object store, a backup server, a vault), keep them encrypted, keep that key apart from the copies and restrict who can read them, with the same rules as the host itself. A backup plus its key is the whole database.
What the product already does
- Automatic backups are encrypted. The installer schedules a daily backup, encrypted with AES-256, with 7 days of retention by default. See Backups on the Control installation page.
- Installation files are readable by root only. The configuration, the initial credentials, the TLS private key and the backup directory are created with restricted permissions, and the CLI runs with
sudo. - Stored credentials are not echoed back. The API returns the sentinel
••••••••in place of a stored destination credential (Target Folders report only whether a password is set), and the MCP server hands the assistant a fingerprint of a stream key instead of its value. See Destinations and MCP tools.
Recommendations
The deployment should also:
- Rotate the stream keys of every destination if a host, a disk image or a backup may have been exposed. YouTube, Twitch and the other providers let you reset the key from their studio; then update the destination in Live Control.
- Review periodically who holds the System Administrator role in Users, together with the API tokens issued to those accounts. Administrators manage destinations and their credentials; an unused administrator account is a standing risk.
Shared responsibility
| Cires21 (the product) | You (the deployment) |
|---|---|
| Encrypts the automatic backups and keeps them on the host. | Encrypts the host's disks before installing. |
| Creates the installation files with root-only permissions. | Restricts host access to named administrators with SSH keys. |
| Keeps the database on the stack's internal network and exposes the data only through the API. | Keeps the database port closed and filters the published ports. |
| Does not echo stored credentials back through the API or the assistant. | Protects every off-host copy of a backup as it protects the host. |
| Publishes security fixes as product updates. | Applies product updates and the host's OS security updates (see Updates). |
| Rotates keys after an exposure and reviews the administrator list. |
Cross-links
- Prepare the host — DNS, NTP,
ufw, swap before the install. - Install C21 Live Control — backups, SSL and the security commands of the CLI.
- Users — roles and API tokens.
- Security — sessions, lockout and password policy of the instance.
Install C21 Live Control and C21 Live Encoder on one host
Run C21 Live Control and C21 Live Encoder on a single host — port layout, install order, the move of Control to port 9443, licenses, certificate, firewall and the impact of updates.
Overview
Build against C21 Live Control — the REST API at /c21apiv2 and the MCP server, both behind one bearer token.