How do I transfer files to a cloud GPU?

Use scp -P <ssh-port> for a few files and rsync -avP -e "ssh -p <ssh-port>" for folders, both run from your own computer with the SSH host, port, user and password of your CloudGPU instance; for small files you can also drag them into the JupyterLab file browser.

Updated 2026-10-27

This guide follows the official rsync, OpenSSH scp, GNU tar, JupyterLab, Microsoft OpenSSH and Hugging Face CLI documentation, read on 2026-10-27, and CloudGPU’s own /deploy, /docs and /terms pages, read the same day.

Which method should I use?

What you are moving Method Why
One file or a few files scp One command, nothing to install beyond an SSH client
A folder you will send again after edits rsync -avP Re-running copies only what changed and keeps partly sent files
Many small files (image sets, text shards) tar piped over ssh One stream instead of one copy per file
A handful of small files, no terminal JupyterLab Upload Files / Download Works in the browser
A model or dataset already on the Hugging Face Hub hf download on the instance The instance pulls it directly; nothing passes through your computer
Results you want to keep rsync or scp run from your computer, before you destroy the instance Files on the instance are deleted when it is destroyed

What you need

  • On CloudGPU: an instance from /deploy using the Raw GPU option, which our deploy page describes as SSH access to a dedicated container where you install the Python and CUDA libraries you want. Each running instance shows an SSH host, port, user and password in your dashboard.
  • On your computer: an SSH client. macOS and Linux include ssh and scp in the terminal. On Windows, Microsoft’s Get started with OpenSSH for Windows page explains how to add the OpenSSH Client optional feature on Windows 10 (build 1809) and later. That feature gives you ssh and scp; it does not add rsync, so on Windows use scp, tar over ssh, or the JupyterLab upload.

Which card you pick does not change how file transfer works. Cards listed on /pricing on 2026-10-27 include the RTX 5090 32G, RTX 4090 48G, RTX 4090 24G, RTX 3090 24G, A100 80G, A100 40G, A800 80G, A800 40G, H20 96G and RTX PRO 6000 96G. VRAM need depends on model, precision and workflow; see How much VRAM do I need to run an LLM?.

GPU time is billed per minute, rounded up, with a 1-minute minimum, and billing stops when you destroy the instance (see /terms). The instance keeps running while you upload, so prepare and compress your data before you deploy.

Step 1: Deploy a Raw GPU and copy the SSH details

  1. Open /deploy and choose Raw GPU (under “Need SSH + your own environment?”).
  2. Pick a card and deploy.
  3. When the instance is running, copy its SSH host, port, user and password from the dashboard. Every command below uses these placeholders: <ssh-host>, <ssh-port>, <ssh-user>.

Step 2: Log in and check the environment

From your computer, log in once before copying anything:

ssh -p <ssh-port> <ssh-user>@<ssh-host>

On the instance, check the GPU and toolkit, then check which copy tools you have:

nvidia-smi          # GPU name, driver version, VRAM
nvcc --version      # CUDA toolkit version
pwd                 # shows your current folder
rsync --version     # needed on BOTH ends for rsync
tar --version
mkdir -p /workspace/data /workspace/outputs

The examples in this guide use /workspace as the working folder, the same as our save-work blog post. If your template’s path is different, use what pwd shows instead.

If nvcc is not found, check for a CUDA folder with ls -d /usr/local/cuda*; if there is one, add its bin directory to PATH. nvidia-smi still shows the GPU either way.

The rsync manual says “rsync must be installed on both the source and destination machines.” Check with rsync --version on your computer and on the instance. If rsync isn’t installed, install it with apt or use scp/tar instead.

# on a Debian or Ubuntu based system
apt-get update && apt-get install -y rsync

Step 3: Copy a few files with scp

Run these on your computer, not on the instance:

# upload one file
scp -P <ssh-port> ./train.jsonl <ssh-user>@<ssh-host>:/workspace/data/

# upload a folder
scp -P <ssh-port> -r ./my-project <ssh-user>@<ssh-host>:/workspace/

# download a results folder
scp -P <ssh-port> -r <ssh-user>@<ssh-host>:/workspace/outputs ./outputs-from-gpu

According to the official OpenSSH scp manual, the port flag “is written with a capital ‘P’, because -p is already reserved for preserving the times and mode bits of the file”, and -r copies entire directories. The same manual notes that since OpenSSH 9.0 scp uses the SFTP protocol by default, and that scp asks for a password when one is needed, so paste the instance password at the prompt.

scp does not resume: if the connection drops, the file starts again. For anything large, use rsync.

Step 4: Sync folders with rsync (resumable)

Run on your computer (macOS or Linux):

# upload the CONTENTS of ./dataset into /workspace/data/dataset on the instance
rsync -avP -e "ssh -p <ssh-port>" ./dataset/ <ssh-user>@<ssh-host>:/workspace/data/dataset/

# preview what would be copied, without copying
rsync -avPn -e "ssh -p <ssh-port>" ./dataset/ <ssh-user>@<ssh-host>:/workspace/data/dataset/

# download results back to your computer
rsync -avP -e "ssh -p <ssh-port>" <ssh-user>@<ssh-host>:/workspace/outputs/ ./outputs-from-gpu/

What the flags mean, according to the official rsync manual:

  • -P is “same as --partial --progress”: it keeps partially transferred files and shows progress, so if the connection drops you run the same command again.
  • -e sets the remote shell; the manual’s own example is -e 'ssh -p 2234', which is how you pass the instance’s SSH port.
  • -n (--dry-run) “perform[s] a trial run with no changes made”.
  • A trailing slash on the source means “copy the contents of this directory” rather than “copy the directory by name”. ./dataset/ fills /workspace/data/dataset/; ./dataset would create /workspace/data/dataset/dataset.
  • -z compresses file data during the transfer. It is optional and left out above; try it on a small sample if your data is mostly uncompressed text.

Step 5: Move many small files with tar over SSH

Thousands of small files are awkward to copy one by one. Stream them as one archive instead (works with Windows OpenSSH too, if tar is on your computer):

# upload: pack locally, unpack on the instance into /workspace/data
tar -cf - ./images | ssh -p <ssh-port> <ssh-user>@<ssh-host> "tar -xf - -C /workspace/data"

# download: pack on the instance, unpack locally
ssh -p <ssh-port> <ssh-user>@<ssh-host> "tar -cf - -C /workspace outputs" | tar -xf -

According to the official GNU tar manual, using - as the archive name makes tar write the archive to standard output when creating it and read it from standard input when extracting, and -C changes directory before tar works, so no subshell is needed.

Step 6: Upload or download in JupyterLab (small files)

If your instance gives you JupyterLab, open it in your browser. According to the official JupyterLab docs, files “can be uploaded to the current folder of the file browser by dragging and dropping files onto the file browser, or by clicking the ‘Upload Files’ button”, and any file “can be downloaded by right-clicking its name in the file browser and selecting ‘Download’”. Use this for a few small files; for datasets, use rsync or tar.

Step 7: Pull models and datasets straight from the Hugging Face Hub

If the files are already on the Hub, download them on the instance instead of uploading from your computer. According to the official Hugging Face CLI guide, hf download downloads files from the Hub, --local-dir puts them in a folder you choose, and hf upload sends files back to a repo:

pip install -U "huggingface_hub"
hf download <repo-id> --local-dir /workspace/models/<name>
# gated or private repos: run `hf auth login` first

For more detail, see our guide How do I download a Hugging Face model on a cloud GPU?.

Step 8: Copy your results off before you destroy the instance

Our /terms say that when an instance is destroyed, all data on it is permanently deleted, and you are responsible for backing up what you want to keep. Our /docs add that stopped instances release their GPU and that persistent storage across restarts is on the roadmap. Before you destroy:

  1. Run the download command from Step 4 (or Step 3 / Step 5) from your computer.
  2. Run the same command again; rsync should list nothing new to copy.
  3. Open a copied file locally to check it.
  4. Destroy the instance. Billing stops when you destroy it (see /terms).

More options, including Hugging Face Hub and object-storage uploads, are in our save-work blog post on copying results off before you destroy a cloud GPU.

Check your own setup before a big copy

These are checks you can run yourself; this page does not assume the result.

  • Is rsync installed on the instance? Run rsync --version there (Step 2). If it is not found, install it with apt or use scp/tar instead.
  • Is rsync installed on your computer? Run rsync --version locally. Windows OpenSSH does not include it, so use scp or tar over ssh there.
  • Does a small copy arrive intact? Copy one small file with scp first, then run ls -l /workspace/data on the instance to confirm it is there.
  • Is /workspace your working folder? Run pwd on the instance; if it shows a different path, use that path in the commands.

Troubleshooting

  • The connection fails and the error mentions port 22: you left out the port, so SSH tried its default. Use -P <ssh-port> with scp and -e "ssh -p <ssh-port>" with rsync.
  • rsync: command not found (or “remote command not found”): rsync is missing on one end. If rsync isn’t installed, install it with apt (Step 2) or use scp/tar instead.
  • A folder ended up nested (dataset/dataset): add a trailing slash to the rsync source.
  • The copy stopped before it finished: re-run the same rsync command; -P keeps the partial file.

FAQ

How do I upload a dataset to a cloud GPU?

From your own computer, run rsync over SSH with the instance’s port: rsync -avP -e “ssh -p ” ./dataset/ @:/workspace/data/dataset/. If rsync isn’t installed, install it with apt or use scp -P -r or tar piped over ssh instead.

Why does scp use -P but ssh uses -p for the port?

According to the OpenSSH scp manual, scp writes the port flag with a capital P because lowercase -p already means preserving file times and mode bits. ssh itself uses lowercase -p for the port, which is why rsync takes -e “ssh -p ”.

Can I resume an interrupted transfer?

With rsync, yes: -P keeps partially transferred files, so you run the same command again. scp does not resume and starts the file again.

Can I upload files without a terminal?

Yes, for small files. In JupyterLab on the instance, drag files onto the file browser or click Upload Files, and right-click a file and choose Download to get it back.

What happens to my files when I destroy the instance?

They are permanently deleted, and billing stops when you destroy the instance. Copy anything you want to keep to your computer or the Hugging Face Hub first; see /terms.

Which GPU should I rent for my workload?

File transfer works the same on every card. VRAM need depends on model, precision and workflow; see How much VRAM do I need to run an LLM? on cloudgpu.app/guides.