Secrets
axern secret stores immutable secrets in a namespace. Secrets are referenced by ID from other resources — for example an environment’s --registry-credential-id — and are never embedded in resource specs. Listing and inspection expose metadata only, not secret values.
Create a secret
Section titled “Create a secret”Opaque secrets take one or more key=value entries. Prefer stdin so values do not appear in command arguments. Reference an existing environment variable instead of writing the value literally in a command or heredoc:
printf '%s\n' "API_KEY=$AXERN_SECRET_API_KEY" | \ axern secret create \ --namespace default \ --literal-stdin \ --label team=runtimeThe stdin format accepts one KEY=VALUE entry per line. Blank lines are ignored, values are preserved verbatim, and the JSON-encoded string_data map must not exceed 64 KiB. The CLI intentionally does not accept opaque secret values as command-line arguments.
A Docker registry credential uses the docker-config-json type with a local config file:
axern secret create \ --namespace default \ --type docker-config-json \ --file ~/.docker/config.jsonInspect and delete
Section titled “Inspect and delete”axern secret list --namespace defaultaxern secret get <secret-id>axern secret delete <secret-id>Secrets are immutable. PostgreSQL rejects deletion while an Environment or non-terminal Run has a required reference; optional Run projections do not block deletion. Rotate secrets as a replacement workflow:
- Create a new Secret with the replacement value.
- Update or replace every resource that references the old Secret ID.
- Wait for the replacement Run or Environment to become active and verify it.
- Delete the old Secret only after no active resource references it.
For an Environment registry credential, create a new Environment because the Environment itself is immutable; then point the workload at the new Environment. For secret-env and secret-file projections, submit a new Run that references the replacement Secret.