Put the remote URL in the committed DVC config and put anything sensitive in the Git ignored local config by adding the local flag to the modify command. DVC's documentation says that flag is needed to write sensitive user information to a Git ignored file, so that no secrets are leaked.
Two config files, two jobs
DVC splits settings across files. The shared file, .dvc/config, is committed so a team shares the remote location. The local file, .dvc/config.local, is Git ignored and holds values that belong to one person or one machine.
The docs give an example in which the dvc remote modify command, with the local flag, writes a credential path to the local file, while the remote URL and a setting like connect_timeout go to the shared file. Because the local file is not committed, the docs note that each copy of the repository must configure these values separately.
Why this matters for data science repos
Data versioning repos hold pointers to large datasets, and the remote is where the real data lives. If a key to that remote lands in Git, it lands in history, forks and clones, and removing it from the latest commit does not remove it from history. A leaked key to a bucket holding training data is a data incident, not just an inconvenience.
What goes where
| Setting | File | Committed |
|---|---|---|
| Remote name and URL | .dvc/config | Yes |
| Timeout and other non-sensitive options | .dvc/config | Yes |
| Credential path, keys, tokens | .dvc/config.local | No |
| Anything personal to one developer | .dvc/config.local | No |
The documentation says the local file is added to .gitignore. Check that your repository actually ignores it, because a repo created by hand may differ.
Better than a key in a file
A file with a long lived key is still a secret on a laptop. Where your storage supports it, prefer short lived credentials from your cloud identity tooling, and let the config point at a profile or a path rather than hold the key itself. The example above stores a path to a credentials file, not the key itself.
Review checklist
- Run a search of the repository history for key patterns before you assume it is clean.
- Confirm
.dvc/config.localis ignored in.gitignore. - Make sure the shared config has no access keys, secret keys or tokens.
- Document how a new teammate gets their credentials, so nobody pastes a shared key into chat.
- Rotate any credential that ever appeared in a commit.
- Give each person or job the smallest access to the remote that works, read only where possible.
- Add a secret scanning step to your pull request checks.
For notebook specific habits, see keep API keys out of notebooks.
Safeguard's scanning and policy gates can help catch exposed secrets and risky changes in pull requests. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is the DVC config file safe to commit?
The shared config is meant to be committed, so keep sensitive values out of it and in the local file.
I committed a key once and deleted it. Am I fine?
No. It remains in history. Rotate the credential.
Sources
Last reviewed: 19 October 2026.
