Key points
- There is a single credential interface. Models, MCP servers, Git Apps, webhook sources, and registry auth all reference it rather than storing values themselves.
NOPSAI_MASTER_KEYis the root encryption material for the registry.- Credential values are write-only: the API returns metadata but never the value after submission.
- Credentials are versioned. A rotation creates a new version, and a specific version can be activated or deleted.
- A credential can be disabled without being deleted.
POST /v1/secrets/encryptproduces a GitOps-safe envelope so a secret can live in a configuration repository without being readable there.
How it works
Legacy inline forms — api_key_secret on an model, auth_secret on an MCP server, GITHUB_PRIVATE_KEY and GITHUB_WEBHOOK_SECRET — remain only for migration. New configuration should use credential references.
Losing the master key makes stored credentials unrecoverable. Rotating it requires re-encrypting the registry, so treat it as the most sensitive value in the deployment.
Examples
curl -sX POST "$NOPSAI_URL/v1/system/credentials" \
-H "Authorization: Bearer $NOPSAI_TOKEN" \
-H "Content-Type: application/json" \
--data @credential.json | jq -r .id
# rotation adds a version; activation decides which one is in use
curl -sX PUT "$NOPSAI_URL/v1/system/credentials/$CREDENTIAL_ID/value" \
-H "Authorization: Bearer $NOPSAI_TOKEN" \
-H "Content-Type: application/json" \
--data @new-value.json | jqImplementation evidence
doc/credential-management.mdEncrypted registry, GitOps envelopes, AAA, rotation, and migration.
services/nopsai/credential_schema.goCredential schema and version handling.

