Secrets

A secret is a named set of key-value pairs holding credentials your agents and services need: API tokens, database passwords, anything that should not sit in a configuration file. Secrets belong to the project and nothing outside it can read them.

Grouping matters here. One secret can carry a host, a user, and a password together rather than forcing three separate entries, so a secret usually maps to a system rather than to a single credential. Add the pairs one at a time, or paste a whole set in with Import from JSON.

Values are write-only. Once saved, a secret's keys stay visible but its values cannot be read back, so editing means supplying new ones. Individual keys can be replaced or removed without touching the rest.

Using a secret

Agents and services attach secrets rather than copying values out of them. Select the ones a deployment needs, on an agent's Runtime step or a service's Environment and Secrets section, and every key inside each attached secret arrives as an environment variable when the container starts.

Those environment variables are what the ${...} reference fields elsewhere in the platform read. A password field on an agent's database connection takes ${MY_SECRET_KEY} rather than the password itself, so the credential never appears in a configuration or in its version history.

Database secrets

Creating a database generates its credentials for you. Two secrets appear, typed database rather than project, one for application access and one for the superuser, each holding the connection details: database name, host, the connection URIs, and credentials. Attach the application one to whatever needs to connect and leave the superuser for administrative work.

Secrets can also be managed from the command line. See the CLI documentation for iai secrets.