Skip to main content
Version: 1.0-beta

Secrets

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.

Passing secrets​

Secrets are passed to functions via provider URIs:

# From environment variables
dagger api call deploy --token=env:DEPLOY_TOKEN

# From files
dagger api call deploy --token=file:./secrets/token.txt

# From command output
dagger api call deploy --token=cmd:"aws sts get-session-token --query Token"

Providers​

Environment variables​

dagger api call my-function --secret=env:MY_SECRET

Reads the value of MY_SECRET from the host environment.

Files​

dagger api call my-function --secret=file:/path/to/secret

Reads the secret from a file on the host.

Command output​

dagger api call my-function --secret=cmd:"command to run"

Runs the command on the host and uses its stdout as the secret value.

HashiCorp Vault​

Dagger can resolve secrets directly from Vault using the vault:// scheme. Only KVv2 mounts are supported.

​shell dagger api call my-function --secret=vault://secret/foo/bar.token ​

Reads the token field of the KVv2 secret foo/bar from the secret mount.

URI format: vault://<mount>/<path>.<field> — the mount is the first path segment, the field is everything after the last dot.

Caching: by default, ttl is infinite. Add ?ttl=1h to cache the resolved value client-side for the given duration.

Authentication: requires the Dagger CLI to be authenticated with Vault via VAULT_ADDR, plus auth-method-specific variables:

  • VAULT_TOKEN — token authentication
  • VAULT_APPROLE_MOUNT_PATH, VAULT_APPROLE_ROLE_ID, VAULT_APPROLE_SECRET_ID — AppRole authentication
  • VAULT_OIDC_MOUNT_PATH, VAULT_OIDC_CALLBACK_PORT, VAULT_OIDC_ROLE, VAULT_OIDC_SKIP_BROWSER - OIDC authentication

1Password​

dagger api call my-function --secret=op://vault-name/item-name/field

Reads from 1Password. Requires authentication via op signin.

AWS Secrets Manager​

dagger api call my-function --secret=aws+sm://prod/my-secret

For JSON secrets, extract a specific field:

dagger api call my-function --secret=aws+sm://prod/database?field=password

Options: ?region=us-west-2, ?version=<id>, ?stage=AWSPREVIOUS.

AWS Parameter Store​

dagger api call my-function --secret=aws+ps://prod/api-key

Reads the parameter /prod/api-key (the leading slash is added for you). SecureString parameters are automatically decrypted.

AWS authentication​

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.

Google Cloud Secret Manager​

dagger api call my-function --secret=gcp://my-secret

A bare name reads the secret from the project set by GCP_PROJECT_ID, GOOGLE_CLOUD_PROJECT, or GCLOUD_PROJECT. Use gcp://projects/PROJECT_ID/secrets/SECRET_NAME/versions/VERSION to specify the project and version explicitly. Authentication uses Application Default Credentials.

libsecret (GNOME Keyring)​

dagger api call my-function --secret=libsecret://login/my-secret

Reads from the host's freedesktop.org Secret Service (e.g. GNOME Keyring) on Linux.

Safeguards​

Dagger ensures secrets never leak:

  • Logs: Secret values are redacted from all output
  • Filesystem: Secrets are never written to container layers
  • Cache: Operations using secrets are excluded from cache keys

If a workflow crashes, secrets remain protected.