Skip to content

Secrets and Secret Injection

Runta separates stored tenant secrets from runtime-scoped injection rules. Store a secret once, then attach a rule to a runtime so matching outbound requests receive a header or parameter value without writing the raw credential into the runtime filesystem.

Use an input method that keeps the value out of shell history.

Terminal window
export OPENAI_API_KEY=sk-example
runta secret add openai-api-key --value-env OPENAI_API_KEY
printf '%s' "$GITHUB_TOKEN" | runta secret add github-token --value-stdin
runta secret add internal-api --prompt --cache-ttl-secs 300

Secret list and get calls return metadata such as ID, display name, and cache TTL. They do not return the stored secret value.

Terminal window
runta secret list
runta secret delete openai-api-key

Rules match a destination host and optional path. The literal ${credential} placeholder is replaced with the stored secret value when the egress gateway injects the outbound request.

Terminal window
runta secret rule add \
worker \
--host api.openai.com \
--path '/v1/*' \
--credential openai-api-key \
--inject-header Authorization \
--inject-value 'Bearer ${credential}'

The CLI currently exposes header injection flags. The SDK injection type also supports parameter injection by setting param instead of header.

The CLI can load YAML rule files:

rules:
- runtime: worker
host: api.openai.com
path: /v1/*
credential: openai-api-key
inject:
header: Authorization
value: Bearer ${credential}
Terminal window
runta secret rule add -f openai-rule.yaml
Terminal window
runta secret rule list worker
runta secret rule delete <rule-id>

Tenant-wide rule listing is available through runta.secrets.list_rules() in Python and runta.secrets.listRules() in TypeScript.