# Stop vs destroy GPU instance: saving money without losing work

URL: https://cloudj.net/blog/stop-vs-destroy-gpu-instance
Published: 2026-11-12 · Updated: 2026-11-12

> 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.

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](https://cloudj.net/blog/estimate-gpu-cloud-cost) covers running, stopped and bandwidth charges together.

## What each action does

| | Running | Stopped | Destroyed |
|---|---|---|---|
| GPU | Yours | Released; someone else may rent it | Released |
| Disk and files | Kept | Kept | Deleted permanently |
| Billing | Running price: GPU + disk, per minute | Stopped price: storage only | Nothing further |
| Bandwidth | Charged per GB | Charged per GB if used | Final charges settle |
| Deposit | Held | Held | Unused part returns, up to 72 hours later |
| Restart | Not needed | May 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](https://cloudj.net/blog/backup-gpu-instance-before-contract-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](https://cloudj.net/blog/jupyter-gpu-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:

```bash
rsync -avP -e "ssh -p <port>" root@<host>:/workspace/ ./backup-$(date +%F)/
```

3. Open a couple of the copied files locally to confirm they are complete.
4. Write down anything about the environment you will need next time (packages, versions, commands), or keep it in a setup script.
5. 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](https://cloudj.net/blog/hourly-vs-monthly-vps) 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](https://cloudj.net/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](https://app.cloudj.net/deploy/gpu), 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.