Virtually every time the Object reference has a value that is a secret (certificate, DNS API token, etc), it is SecretText, meaning you can tell Stalwart to load it from an inline value, file, or environment variable. Account, however, does not have its Password Credentials in this form, they are always inline, which causes problems when configuring declaratively.
For example, with NixOS, you can set Stalwart to read a DNS API token from a secret file decrypted by sops-nix, but if you want to set a user’s password, you have to end up with their password in the actual stalwart-cli apply plan file, which breaks secrecy.
Ideally, this would be fixed by making PasswordCredential.secret into a SecretText, but that would be backwards-incompatible, so perhaps Credential could have two new variants: PasswordCredentialFile and PasswordCredentialEnv
This confirms the observation: PasswordCredential.secret is a plain String, not SecretText, unlike secrets used elsewhere in the schema (certificates, DNS tokens, OIDC providers, etc.), which do support SecretText (inline, file, or env-var forms). There is no current mechanism to load an account password from a file or environment variable via declarative config; it must be inline.
This is a legitimate feature request rather than something documented as configurable today, so I can’t point you to a workaround in the docs.
This isn’t covered in the current docs. A community member or staff member will follow up.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.