MLOpsThe MLOps lifecycle · MLflow 3.17 · DVC 3.67 · FastAPI · Docker · GitHub Actions · Evidently · Python 3.11+
Dashboard
0%
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
50 small wins to finish your pathNext lesson →

DVC remote storage

A DVC remote is a storage location, a folder or a cloud bucket, that holds a copy of the cache so anyone with the repository can fetch the content its pointers name.

Last updated: 19 Oct, 2026 · MLOps

After Tracking data with DVC the content sits in one cache on one machine. A teammate who clones the repository gets the pointer and an md5 with nothing behind it. A remote is the copy that fixes that, and it is also the backup, since a cache lives inside a folder somebody can delete.

Adding a default remote

A remote has a name and a location. The -d flag makes it the default, so later commands need no name at all. The location here is an ordinary folder outside the repository, which behaves exactly like a cloud bucket and costs nothing to try.

ExampleA local folder set up as the default remote
dvc remote add -d localstore ~/dvcstore
cat .dvc/config

The setting lands in .dvc/config, which is a git-tracked file, so committing it tells everyone else where the data lives. The DVC docs use the same shape for their own examples, /tmp/dvcstore and ../dvcstore.

Pushing the cache to the remote

ExampleWhat a push puts in the remote
dvc push
find ~/dvcstore -type f
  • One file was sent, because one file is tracked. The count is of cached contents, not of commits.
  • The path is the hash again. The remote has no data/ folder and no file called stud.csv; it has files/md5/6d/115d..., the same layout as the cache.
  • Identical content is stored once. Two branches, ten commits and three file names that hold the same bytes share one object in the remote.

Fetching the data back with dvc pull

This is what a clone looks like from the other side. Throwing away the cache and the file leaves the repository with the pointer alone, which is all a teammate ever has.

ExampleA pointer with no content, and the pull that fills it
rm -rf .dvc/cache data/stud.csv
dvc pull
wc -c < data/stud.csv

dvc pull fetched the content into the cache and checked it out into the working folder, so git clone followed by dvc pull is the whole setup a new machine needs.

Pointing a remote at S3, Google Drive or Azure

A cloud remote is the same command with a different URL, plus the extra that brings the backend for that service. Each line below replaces the local folder; a project has one default remote, not three.

bash
pip install "dvc[s3]"

dvc remote add -d storage s3://my-bucket/dvcstore
dvc remote add -d storage gdrive://0AIac4JZqHhKmUk9PDA/dvcstore
dvc remote add -d storage azure://my-container/dvcstore
  • The extra matters. dvc[s3], dvc[gdrive], dvc[azure] and dvc[gs] each pull in the library for that service. Without one, the URL is refused.
  • Credentials are the service's own. The S3 backend reads what the AWS CLI already set up; Google Drive asks you to authorise it once in a browser.
  • Nothing here was run. These three lines come from the DVC remote-storage docs linked below, and a cloud account is the one thing this course does not spend.
  • The commands after it do not change. dvc push and dvc pull behave the same whichever URL the default remote carries.

A folder remote vs a cloud remote

A folder on diskA cloud bucket
Set up withdvc remote add -d localstore ~/dvcstoredvc remote add -d storage s3://bucket/path
NeedsNothingThe matching extra and credentials
Reachable fromThis machine, or a shared mountAny machine with the credentials
Good forLearning, and a single-machine backupA team, and a build machine

Where a remote earns its keep

  • A second person on the project. They clone, pull, and are on the same bytes as you without a message asking for the file.
  • A build machine that retrains. It has no shared drive, so the remote is its only route to the data.
  • The machine dies. The cache went with it; the remote did not.
Watch out. Pushing is a separate step from committing. git push sends pointers and dvc push sends content, and nothing warns you when you do the first without the second. The teammate's error then arrives far away from the mistake, as a missing file for a hash nobody can find.
Try it yourself
  • Run dvc push twice. The second push sends nothing, because the remote already holds that content.
  • Add a second remote with dvc remote add backup ~/dvcbackup and push to it by name with dvc push -r backup.
  • Delete ~/dvcstore and run dvc status -c, which lists the file as missing once the remote no longer holds it.
PreviousTracking data with DVC

Every expert started right here.