Save your work, then stop your GPU

The one thing I want everyone to know before their first session on DeployGPU is this: Stop is not pause. Stopping a GPU instance terminates it at the provider and deletes its disk, so the only safe order is to save your work first and stop second. Do it in that order and stopping is the cheapest button on the platform, because the unused part of the hour comes straight back to your balance.

The stop dialog in the dashboard says you are charged only for the time used, which is true, but it does not say the disk goes with it. That gap is why this page exists.

The checklist before you press Stop

The list is short on purpose, so it actually gets done:

1. Push code to git: git add -A && git commit -m "wip" && git push.
2. Download or push notebooks. In JupyterLab, right-click a notebook and choose Download, or commit the folder.
3. Upload model checkpoints and adapters somewhere that outlives the VM: the Hugging Face Hub, your own object storage, or your machine.
4. Copy outputs off with rsync or scp (commands below).
5. In Open WebUI, export the chats you want. In ComfyUI, download outputs and save the workflow JSON.
6. Write down the model IDs and package versions you used, so the next session starts the same way.

Moving files off the machine

From your own computer, rsync pulls a folder down and can resume if the connection drops. Use the user, host and port from the SSH command shown on your deployment:

# Pull ~/outputs from the VM into ./outputs on your machine
rsync -avz --progress -e "ssh -p 22" ubuntu@YOUR_VM_IP:~/outputs/ ./outputs/

# One file with scp
scp -P 22 ubuntu@YOUR_VM_IP:~/model/adapter_model.safetensors .

For checkpoints, the Hugging Face Hub is usually faster than your home connection, because the upload runs from the datacenter. With the huggingface_hub package installed and a write token in HF_TOKEN:

pip install -U huggingface_hub
hf upload your-name/my-finetune ./checkpoints/final --private

Older versions of the package call the command huggingface-cli upload with the same arguments.

The SSH username differs by provider, which trips people up here more than anywhere: ubuntu on QuantaCloud and Hyperstack, Ubuntu with a capital U on Massed Compute, and root on Verda. The SSH guide has the full table.

Where data can live between sessions

A volume is the right tool when you come back to the same dataset every day on the same provider. It is the wrong tool as your only copy of anything, because of that second column. The first time you attach one, find the device and format it. After that, only mount it:

lsblk                                  # find the new disk, for example /dev/vdb
sudo mkfs.ext4 /dev/vdb                # first use only: this erases the volume
sudo mkdir -p /mnt/data
sudo mount /dev/vdb /mnt/data

The device name depends on the provider, so check lsblk every time rather than copying a name from a previous session. The volumes documentation covers creating and attaching them.

What you pay when you stop

Launching reserves the first hour from your balance. After that, each new hour is charged when it starts. When you stop, the unused seconds of the current hour come back. Two more rules matter:

• Stop before the machine reaches Running and the whole reserved hour comes back.
• If the launch fails on the provider's side, the reserved hour is refunded automatically.

A worked example: you launch, work for 3 hours and 10 minutes, and stop. Four hours were charged as they started, the unused 50 minutes of the fourth come back, and you paid for exactly 3 hours and 10 minutes at the hourly rate you launched at. The pricing page has the rest of the mechanics, including the card processing fee on top-ups.

Do not pay for idle time

DeployGPU has no idle detection, no auto-stop timer and no maximum runtime. A GPU you forget about runs, and bills, until you stop it or your balance runs out. The rule I would give anyone is simple: stop the instance the moment the last file has landed on your machine, not after dinner.

If you launch through the API, two scripts help. A job can stop its own instance when it finishes:

python train.py && curl -s -X POST \
  "https://api.deploygpu.ai/api/v1/deployments/$DEPLOYMENT_ID/stop" \
  -H "X-API-Key: $DEPLOYGPU_API_KEY"

Be careful where that key lives. DeployGPU API keys have no scopes, so a key copied onto a VM can do anything your account can do, including launching more GPUs. Use a key you create for this purpose and delete it when you are done.

A guardrail on your own machine or a cron job can stop anything that has run too long:

import datetime
import os

import requests

API = "https://api.deploygpu.ai/api/v1"
HEADERS = {"X-API-Key": os.environ["DEPLOYGPU_API_KEY"]}
MAX_HOURS = 8

resp = requests.get(f"{API}/deployments", headers=HEADERS, params={"size": 100})
resp.raise_for_status()
now = datetime.datetime.now(datetime.timezone.utc)
for d in resp.json()["data"]:
    if d["status"] != "active" or not d["activated_at"]:
        continue
    started = datetime.datetime.fromisoformat(d["activated_at"].replace("Z", "+00:00"))
    hours = (now - started).total_seconds() / 3600
    if hours > MAX_HOURS:
        print(f"Stopping {d['id']} after {hours:.1f} hours")
        requests.post(f"{API}/deployments/{d['id']}/stop", headers=HEADERS).raise_for_status()

DELETE /api/v1/deployments/{id} does the same as the stop call. The API page covers keys and limits.

When your balance runs out mid-job

When the balance cannot cover the next hour, the instance does not stop at once. It switches to per-minute billing and keeps running until the balance reaches zero, then it is stopped and its disk deleted like any other stop. You get an email when about two hours of runtime are left, another when per-minute billing starts, and a last one when the instance is stopped.

Volumes get no such warning. The first volume-hour your balance cannot pay deletes the volume permanently. If a volume holds anything you care about, turn on auto top-up on the billing page or keep a buffer of credit, and keep a second copy somewhere else.

If the provider loses your machine

Hardware fails occasionally. DeployGPU checks every running instance every 5 minutes, and when a provider confirms a machine is gone, the deployment is stopped and the unused time refunded. Two things to know today: no email is sent when that happens, and the deployment disappears from your dashboard list. If an instance vanishes, that is almost always the reason. The disk is gone with the machine, which is one more reason to copy results off as you go rather than at the end.