Data Persistence - QuantaCloud

Every QuantaCloud instance comes with the disk included in its offer, and that disk exists only as long as the instance does. There are no volumes and no snapshots, so nothing on the disk survives the end of a deployment.

Stopping a deployment terminates the instance and deletes its disk. There is no pause or stop/start, and a deleted disk can’t be recovered. Copy anything you need off the instance before you stop it.

When the disk is deleted

Event	What happens
You stop the deployment in the console, or call `POST /api/v1/deployments/{id}/stop` or `DELETE /api/v1/deployments/{id}`	The instance is terminated and its disk is deleted. The unused seconds of the current hour are refunded to your balance.
Your balance can’t cover the next hour	The deployment is terminated and its disk is deleted. There is no grace period.
The deployment’s status is `interrupted`	The instance was terminated outside your control, after a host failure or a failed health check. Treat its disk as lost.
Provisioning fails, or you stop the deployment before it is running	The instance is terminated, and the first hour is refunded in full.

A low-balance email goes out when your balance falls below

2, at most once every 24 hours. Termination doesn't wait for it: if the next hour costs more than what's left, the deployment is terminated even while your balance is above

2. Turn on auto top-up for anything that runs unattended.

What lives on the disk

Everything you create or install on the instance is on its disk, including:

Files in the ubuntu home directory and anywhere else on the filesystem
Packages and Python environments you installed
Docker images, containers and Docker volumes
Models and datasets you downloaded, for example the Hugging Face cache in ~/.cache/huggingface
Data inside app template containers: Jupyter notebooks, Open WebUI chats, uploads and knowledge bases, ComfyUI models and outputs
Credentials you stored on the instance, such as API keys and access tokens

Deleting the disk deletes a credential file, not the credential. An API key stored on the instance keeps working until you revoke it under API Keys.

Copy results off with scp or rsync

Run these on your own machine, with the host and port from the Deployments page:

# Download one file
scp -i ~/.ssh/your_key -P <port> ubuntu@<host>:~/outputs/model.safetensors ./

# Download a directory; repeat runs send only files that changed
rsync -avz -e "ssh -i ~/.ssh/your_key -p <port>" ubuntu@<host>:~/outputs/ ./outputs/

App templates keep their data inside a Docker container. SSH in, find the container with sudo docker ps, copy the folder to the host with sudo docker cp <container>:<path> ./<folder>, then download it as above. Templates describes each app, and Open WebUI can also export your chats from Settings > Data Controls > Export Chats. The guide to moving datasets and checkpoints to and from a cloud GPU covers larger transfers.

Push to object storage or the Hugging Face Hub

For results you want off the instance while a job is still running, push them to storage you control. S3-compatible object storage works with tools such as rclone or the AWS CLI, installed on the instance with your own credentials. Checkpoints and datasets can go to a private Hugging Face repository with the hf CLI:

hf auth login
hf upload your-name/my-checkpoints ./outputs . --private

hf upload creates the repository if it doesn’t exist. Add --every=10 to keep the command running and upload new or changed files every 10 minutes while training runs, until you press Ctrl+C. An unexpected stop then loses only the work since the last upload. You don’t need to back up public models. Download them again on the next instance, as shown in the guide to downloading Hugging Face models fast.

Keep code in git

Commit and push your code before you stop. A repository you push to regularly is the simplest backup for code, notebooks and configuration files, and cloning it is the first step on the next instance.

Script your setup

Every instance starts clean, from the same base image. The fastest way back to work is a setup script that rebuilds your environment on a new instance: clone your repository, install packages, pull your Docker image, download models and copy your data back. Keep it in your repository and run it once the new instance is Running:

ssh -i ~/.ssh/your_key -p <port> ubuntu@<host> 'bash -s' < setup.sh

A minimal setup.sh for a project that runs in its own Docker image:

#!/usr/bin/env bash
set -euo pipefail
git clone https://github.com/your-org/your-project.git ~/project
sudo docker pull ghcr.io/your-org/your-image:1.0

The Bare Metal template already includes the NVIDIA driver and Docker, so an image of your own is usually the quickest environment to restore. API deployments boot the same image, so a script can launch an instance and set it up without the console. See the API Quickstart.

Before you stop

Copy outputs and checkpoints off the instance, or confirm your last upload finished.
Push your code.
Export app data you want to keep, such as Open WebUI chats or files inside a template’s container.
Add anything you installed by hand to your setup script.
Revoke API keys or tokens stored on the instance that you won’t reuse.
Stop the deployment.

Billing: when deployments are terminated, refunds, and auto top-up
Connect via SSH: more scp and rsync examples
Stop paying for idle GPUs: stop an instance automatically when its GPUs sit idle

​When the disk is deleted

​What lives on the disk

​Copy results off with scp or rsync

​Push to object storage or the Hugging Face Hub

​Keep code in git

​Script your setup

​Before you stop

​Related

When the disk is deleted

What lives on the disk

Copy results off with scp or rsync

Push to object storage or the Hugging Face Hub

Keep code in git

Script your setup

Before you stop

Related