Secrets
Handle secrets, log masking, and diagnostics safely.
Secret values are for runtime use and should not appear in read models, logs, diagnostics, support payloads, or effective-config responses as plaintext.
Users should see the existence and state of a secret, such as masked value, last update time, source environment, and whether it participates in deployment snapshots. They should not see plaintext values.
Resource-level secrets can be created with appaloft resource secrets create, rotated with
update, removed with delete, and inspected with list/show. Those operations affect future
deployment snapshots only; they do not hot-update a running instance.
When pasted .env content is imported into a resource, Appaloft treats secret-like keys as runtime
secrets, such as DATABASE_URL, *_TOKEN, *_PASSWORD, and *_PRIVATE_KEY. Import summaries,
API, CLI, Web, logs, and diagnostics should show only masked values.
Build-time variables cannot be marked secret because they can become part of build artifacts.
If a variable can enter a browser bundle, static file, or build artifact, it is not a secret. Do not put database passwords, API tokens, or private keys in build-time variables.
Build-time variables must use the PUBLIC_ or VITE_ prefix. Build-time variables with
secret-like names are rejected instead of being silently downgraded to plain config.
After rotating a secret, redeploy resources so running instances read the new deployment snapshot.
Recommended flow:
- Set the new secret in the target environment or use
appaloft resource secrets rotatefor a resource-specific secret. - Create new deployments for affected resources.
- Confirm health and logs show the app reading the new value safely.
- Confirm the old secret is no longer used.
- Revoke the old secret in the external system.
When copying diagnostics, copy key names, masked state, error codes, and related deployment ids. Do not copy .env files, full variable tables, or secret values.
Related page: Diagnostics.