Manage Secrets

Runtime configurations store your credentials and settings. They are synced from your local .dlt/ directory and versioned separately from your code.

How secrets flow to Runtime

Local .dlt/ directory  →  dlt runtime deploy  →  Runtime Configuration (versioned)

When you run dlt runtime deploy or dlt runtime launch, the contents of your .dlt/ directory are synced as a new configuration version. This includes secrets.toml, config.toml, and any profile-specific files.

Profile-specific credentials

Runtime uses profiles to separate credentials for different job types:

Profile	Used by	Typical access level
prod	Batch jobs (dlt runtime launch)	Read-write
access	Interactive apps (dlt runtime serve)	Read-only

Configure profile-specific secrets in separate files:

.dlt/
├── secrets.toml            # Shared secrets (Runtime invite code, etc.)
├── secrets.prod.toml       # Batch job credentials (read-write)
├── secrets.access.toml     # Interactive app credentials (read-only)
├── config.toml             # Shared config
└── config.prod.toml        # Batch job config overrides

Example secrets.prod.toml (read-write for batch pipelines):

[destination.motherduck.credentials]
database = "my_db"
password = "rw-token"

Example secrets.access.toml (read-only for notebooks):

[destination.motherduck.credentials]
database = "my_db"
password = "ro-token"

For more on profiles, see the Profiles documentation in the dlt docs.

Update secrets

Edit your local .dlt/secrets.toml (or profile-specific file) and sync:

dlt runtime configuration sync

Or sync everything (code + config) at once:

dlt runtime deploy

See dlt runtime configuration sync.

View configuration versions

From the CLI

dlt runtime configuration list
dlt runtime configuration info

See dlt runtime configuration list and dlt runtime configuration info.

From the Web UI

The Deployment & Config page shows the current configuration version, timestamp, and file tree.

Best practices

• Never commit secrets to git. Add .dlt/secrets.toml and profile-specific secret files to .gitignore.
• Use read-only credentials for interactive apps. The access profile powers shared notebooks -- public users should not have write access.
• Use separate credentials per profile. This ensures batch pipelines have the access they need while interactive apps remain safely read-only.
• For CI/CD deployments, see the CI/CD Integration guide.