Configuration

Operational settings are edited in the web console under Settings. Service settings live in master.env and worker.env beside each executable; the launcher loads the file before starting the service.

Configuration lives in two places. Operational settings (presets, alerts, integrations, user accounts) are edited in the web console under Settings and take effect without a restart. Service settings — addresses, ports, storage, secrets — are read from the environment file: each file is read as environment variables, values set directly in the process environment override the file, and changes take effect when the service is restarted.

Settings in the web console#

The Settings area is four sub-pages behind a navigation rail. Opening Settings from the sidebar — or the root /settings route, which redirects to General — lands on the General sub-page. Non-administrators see only General; the other three sub-pages are administrator surfaces.

General holds the personal settings — the settings rail labels it Personal. Its panels are documented where their subjects are: the theme picker in Themes & appearance, the Licensing panel in Licensing, and the Notifications panel in Notifications.

Operations gathers the panels that shape day-to-day encoding: alert channels (webhook, Slack and email notifications for job and worker events), the preset editor with its live FFmpeg command preview, and — further down the page — recurring jobs and job templates.

Integrations holds the MAM panel — connections, deliverable matrices and recent writes — the Flow Production Tracking panel, and Cloud Burst. Saving a MAM or Flow connection requires the matching vault key from Integrations and vault keys; the Flow panel reports itself disabled until TRNSCODE_FLOW_VAULT_KEY is set.

Access is where administrators create operator and viewer accounts, reset passwords, and issue API tokens for headless use of the REST API. A new user is forced through a password change on first sign-in, and a token's plaintext is shown once, at creation.

Environment variable naming#

Each variable name is the setting name in upper case, preceded by a service prefix:

Two naming errors account for most misconfigurations:

• A worker variable placed in master.env, or a master variable placed in worker.env. Each service reads only variables carrying its own prefix.
• Variables named TRNSCODE_MASTER_<NAME>. Master settings use the TRNSCODE_ prefix alone; the MASTER_ segment is not part of any setting name.

Three variables are exceptions to the prefix rule. They are read directly by the tooling resolvers and are the only supported names of this form:

• TRNSCODE_MASTER_OIIOTOOL_PATH
• TRNSCODE_MASTER_OCIOBAKELUT_PATH
• TRNSCODE_MASTER_OCIO_CONFIG_PATH

Environment file resolution order#

Both executables load their environment file automatically. Three locations are read in order, and later locations override earlier ones:

This order allows a master.env placed beside the executable to be loaded when the executable is launched directly, with no launcher script. The worker resolves worker.env the same way.

Master — listening#

Master — storage#

The parent directory is created if it does not exist, so any writable path is accepted. This file is the backup target for the deployment. Use master backup rather than copying the file while the service is running.

Master — authentication#

Master — fleet policy#

Master — logging#

Worker — discovery#

Worker — runtime#

Integrations and vault keys#

Credentials for external systems are encrypted at rest, and the key that encrypts them is environment-only — it is never stored in the database. When the key is not set, the master refuses to save a connection rather than store a secret it cannot protect.

Image, colour and font tooling#

All of these tools ship inside the master executable, so a standard installation requires none of them. Set them only when the deployment must use a site-provided build.

Run master probe-v-deps to see which of these resolve and where.

Security and confinement#

Behaviour and housekeeping#

Scheduled backups#

The master can take periodic online backups of its database. The schedule and retention are set in the console under Settings → Operations → Backups; the environment variables below only seed that panel's defaults, and the values saved in the panel win at runtime. The full workflow — the verified archive format, listing and downloading a backup, and restoring one — is on the Backups page.

Applying changes#

Environment-file settings are read at startup. Edit the file, then restart the affected service: the master for master settings, the relevant worker for worker settings. Changing a master fleet-policy setting does not retroactively admit workers that were already refused; they must attempt registration again.