Starling configuration

Starling reads starling.toml. A file overlays built-in defaults: omitted keys keep their defaults, while unknown keys cause startup to fail. For an existing deployment, use Migrating to Starling.

A small server

[[instances]]
name = "Frog Pond"
port = 64738

[instances.settings]
max_users = 20
password = ""
welcome_text = "Welcome!"

On a first local all-in-one run without a config argument, Starling writes a starter configuration in its platform configuration directory. In Docker Compose, edit deploy/starling.toml, which is mounted into every service. For a custom all-in-one deployment, copy starling.example.toml.

Settings under the instances.settings table, such as max_users, password, and welcome_text, can also be changed from the admin UI. A value changed at runtime takes precedence over its starting value in TOML. Deployment settings such as endpoints and TLS paths stay in TOML.

Services and feature settings

Services use services.NAME tables. To turn a built-in service off, set enabled = false; leaving a table out keeps its default. The operator API is an exception: it is absent until explicitly configured. Files use the services.files table with an HTTP listen address and a client-reachable public_url. Screen-share relay needs a reachable media address. See the configuration guide and reference TOML for the full schema.

Starling can reload supported settings on SIGHUP. Listener changes can require a restart; check the reload log for applied, next_connection, and pending_restart. See Migrating to Starling for configuration conversion and database import.