Skip to content
Cloudj

GPU how-to

Stop vs destroy GPU instance: saving money without losing work

Stop vs destroy GPU instance on Cloudj: what each does to billing, disk and the GPU, how the deposit returns, and a checklist to run before either one.

Updated · 4 min read

Stop vs destroy GPU instance is the decision you make at the end of every working session, and getting it wrong costs either money or work. On Cloudj, Stop keeps your disk and charges storage only, but releases the GPU so someone else can rent it. Destroy deletes the instance and its disk permanently and ends all charges. Neither is "pause". This article explains exactly what each action does, when to use which, and a short checklist to run before you press either button.

If you are estimating the total cost of a project, the GPU cloud cost estimate guide covers running, stopped and bandwidth charges together.

What each action does

RunningStoppedDestroyed
GPUYoursReleased; someone else may rent itReleased
Disk and filesKeptKeptDeleted permanently
BillingRunning price: GPU + disk, per minuteStopped price: storage onlyNothing further
BandwidthCharged per GBCharged per GB if usedFinal charges settle
DepositHeldHeldUnused part returns, up to 72 hours later
RestartNot neededMay wait for the GPU ("Waiting for GPU")Not possible; deploy a new instance

Two lines in that table cause most surprises.

Stop releases the GPU. A stopped instance does not reserve its card. If another customer rents it, starting again shows "Waiting for GPU" until the card is free. That might be minutes or much longer. If you need a GPU right now, destroy and deploy a new instance on any available machine.

Stopped is not free. Storage is charged while stopped. A large disk left stopped for weeks adds up. The disk size you chose at deploy cannot be reduced later, so that cost is fixed for the life of the instance.

The availability date overrides both

Every machine shows "available until" a date. When that date comes, the instance and its disk are removed, whether it is running or stopped. Stopping does not extend it. If your data must survive past that date, copy it off the machine. The guide to backing up before availability ends has a routine for this.

When to stop

Stop makes sense when all of these are true:

  • You will come back soon, and waiting a while for the GPU is acceptable.
  • Your environment or data on the disk would take long to rebuild.
  • The storage cost for the time away is acceptable.
  • The machine's "available until" date leaves enough time.

Typical case: a multi-day project on a machine with a large prepared dataset, where you stop overnight and accept that the restart might wait.

When to destroy

Destroy is the better choice when any of these are true:

  • You are done, or will not return for a while.
  • You need a GPU immediately next time and cannot risk "Waiting for GPU".
  • Your setup is scripted, so a fresh instance is quick to prepare.
  • The data on the disk is already backed up elsewhere.

Typical case: a student or researcher who works in focused sessions, saves notebooks to Git, and deploys a fresh machine each time. The Jupyter notebook GPU guide for students follows this pattern.

Checklist before you stop

  1. Save open notebooks and stop long-running processes cleanly, so files are not half-written.
  2. Note the machine's "available until" date.
  3. Copy anything critical off the machine anyway; hosts are independent with no hardware SLA.
  4. Accept that restarting may wait for the GPU.

Checklist before you destroy

  1. Commit code and notebooks to Git.
  2. Copy outputs, checkpoints and logs to your own storage:
rsync -avP -e "ssh -p <port>" root@<host>:/workspace/ ./backup-$(date +%F)/
  1. Open a couple of the copied files locally to confirm they are complete.
  2. Write down anything about the environment you will need next time (packages, versions, commands), or keep it in a setup script.
  3. Destroy. Charges stop, and the unused part of the deposit returns to your balance after final bandwidth charges settle, which can take up to 72 hours.

A note on billing for GPUs vs VPS

GPU instances are billed per minute from your prepaid balance, and the price shown at deploy is locked for that instance. There are no long-term plans for GPU instances. Cloudj VPS servers are different: they offer hourly billing or longer terms, which the hourly vs monthly VPS guide explains. If a workload needs to stay up for months without a GPU, a VPS is usually the better home for it.

Live prices for each card are on GPU cloud.

FAQ

Does stopping keep my GPU reserved?

No. Stop releases the GPU. Restarting may wait until it is free.

Do I pay anything while an instance is stopped?

Yes, storage only, at the stopped price.

Can I recover files after destroying?

No. Destroy deletes the instance and its disk permanently. Back up first.

When does my deposit come back?

After you destroy the instance, the unused part returns to your balance, possibly up to 72 hours later while bandwidth charges settle.

Next step

Before you end your next session on the GPU deploy page, run the checklist above. Stop only when you will return soon and can wait for the GPU; otherwise back up, destroy, and deploy fresh next time.

Deploy a server or order proxies

Pick a location in the console, see the live price, and pay from your balance.