Secrets
The credentials your operations call out with are kept in a vault in the project. A value is stored encrypted (the detail is on the security page), addressed by reference and kept out of your config files.
Labels and references
A secret has a label you choose and an owner: the project, an app, or one of your users. Creating it returns an opaque reference, and that reference is how it is addressed from then on. You can store one in the console under Settings, with the CLI, or by committing a foir.secrets.ts file that declares labels and holds no plaintext, which foir secrets push reconciles with the project.
How a value is read
For an endpoint you host, the dispatch token that arrives with the call already grants the read. The handler calls getSecret with the reference and a purpose, and holds no credentials of its own. The purpose is required and is recorded.
For a call Fóir makes itself, the request template refers to a secret by a placeholder name, and a binding on the operation maps that name to the reference. The value is resolved at call time and is never stored on the operation.
Who can hold access
Scopes for secrets can be held by secret API keys and never by public keys. An operation that one of your users triggers can store a secret that user owns, and only that user's operations read it back.
Rotation and deletion
Rotating replaces the value behind an existing reference. Readers get the new value on their next read, and nothing has to be redeployed. Deleting is soft: the secret stops resolving at once and can be restored for 30 days.
Read the detail
The secrets guide covers storing, reading and rotating a secret, secrets owned by a user, and what is audited.