Secrets

The standalone Secrets page lets admins and managers create and rotate Dagu-managed secrets that are referenced directly from DAG YAML.

For named runtime environments selected when a run starts, or for Global/workspace runtime profile defaults, use Profiles. Profile secret entries are created and rotated from the Profiles page, even though Dagu stores their values in the managed secret store internally.

Secrets created here are referenced from DAG YAML with ref:

secrets:
  - name: DB_PASSWORD
    ref: prod/db-password

The DAG receives DB_PASSWORD as an environment variable when the run starts. The plaintext value is not stored in the DAG file.

Secret Scopes

Secrets can be global or workspace-scoped. The same ref can exist globally and in multiple workspace scopes with different values.

Secret scope	Secrets page behavior
Global	Manage workspace-less secrets available to all DAGs as a fallback
Named workspace	Manage secrets for DAGs with labels: [workspace=<name>]

When writing DAG YAML, use only the ref value:

ref: prod/db-password

Do not include the scope or workspace name in the ref. A DAG in workspace=payments first resolves prod/db-password from the payments workspace, then from Global if no workspace-specific secret exists. A DAG without a workspace label resolves it from Global.

Create A Secret

1. Open the standalone Secrets page.
2. Select Global or a named workspace.
3. Click Add Secret.
4. Keep provider set to Dagu Managed.
5. Enter a ref such as prod/db-password. Refs use lowercase slug segments separated by /.
6. Enter the value and save.

The value is write-only. After saving, the API and UI return metadata such as ref, status, version, and timestamps, but not the plaintext value.

Rotate A Secret

Use Rotate from the row action menu to write a new value version. New runs use the latest version. Running steps keep the environment they already received when the run started.

Enable And Disable

Disable a secret to stop new runs from resolving it. A DAG run that references a disabled secret fails during initialization before any steps execute.

Enable the secret again when it should be usable by new runs.

External Providers

External registry-backed providers such as Vault, Kubernetes, and cloud secret managers are request-based in the current UI. Use Request access to contact the Dagu team.

Existing DAG-based direct providers still work without the Web UI registry:

secrets:
  - name: DB_PASSWORD
    provider: env
    key: PROD_DB_PASSWORD

See Workflow Secrets for the full YAML behavior and direct provider reference.

Profile-Owned Secrets

Runtime profile secret entries are profile-owned. This includes entries on named profiles, Global profile defaults, and workspace profile defaults. Manage those values from Profiles so the profile entry and its backing secret stay in sync.

Do not create a standalone secret with the same intent and then expect a runtime profile to pick it up by ref. Standalone secrets are resolved only when DAG YAML references them with secrets[].ref.

Storage

Dagu-managed secrets are stored in Dagu's internal secret store under:

<data_dir>/secrets

Values are encrypted at rest and versioned. The encryption key is resolved from the same data directory, so include the data directory in secure backups if you rely on Dagu-managed secrets.

Permissions

Secret management is intended for administrative users. A user needs manager or admin permission for the selected scope before creating, rotating, enabling, disabling, or deleting secrets.

Related

• Profiles
• Runtime Profiles
• Workflow Secrets
• Workspaces
• User Management