docs/current_docs/adopting/secrets.mdx
Dagger has built-in support for secrets — passwords, API keys, tokens — sourced from multiple providers. Secrets are never exposed in logs, written to container filesystems, or inserted into the cache.
Secrets are passed to functions via provider URIs:
# From environment variables
dagger call deploy --token=env:DEPLOY_TOKEN
# From files
dagger call deploy --token=file:./secrets/token.txt
# From command output
dagger call deploy --token=cmd:"aws sts get-session-token --query Token"
dagger call my-function --secret=env:MY_SECRET
Reads the value of MY_SECRET from the host environment.
dagger call my-function --secret=file:/path/to/secret
Reads the secret from a file on the host.
dagger call my-function --secret=cmd:"command to run"
Runs the command on the host and uses its stdout as the secret value.
dagger call my-function --secret=vault://secret/data/my-app#token
Reads from Vault. Requires the Dagger CLI to be authenticated with Vault (via VAULT_ADDR and VAULT_TOKEN environment variables or other standard Vault auth methods).
dagger call my-function --secret=op://vault-name/item-name/field
Reads from 1Password. Requires authentication via op signin.
dagger call my-function --secret=aws+sm://prod/my-secret
For JSON secrets, extract a specific field:
dagger call my-function --secret=aws+sm://prod/database?field=password
Options: ?region=us-west-2, ?version=<id>, ?stage=AWSPREVIOUS.
dagger call my-function --secret=aws+ps:///prod/api-key
SecureString parameters are automatically decrypted.
Both AWS providers use the default credential chain: environment variables, shared credentials file (~/.aws/credentials), or IAM role (EC2, ECS, Lambda).
Set the region with AWS_REGION or the ?region= query parameter.
Dagger ensures secrets never leak:
If a workflow crashes, secrets remain protected.