Every QuantaCloud GPU instance is its own virtual machine in a US region. You reach it over SSH as ubuntu with your key, browser apps sit behind your QuantaCloud login, and stopping the instance deletes its disk. QuantaCloud is not SOC 2 or HIPAA certified. Reserved builds are quoted separately: your security requirements go in the brief, and the configuration and terms come back in writing.
| Area | How it works today |
|---|---|
| Instances | Each instance is its own virtual machine with its own disk |
| Access | SSH as ubuntu with a key pair |
| Browser apps | A private URL behind your QuantaCloud login, open to the owning account only |
| API | Keys that start with gpu_live_, shown once and revocable at any time |
| Data on stop | The instance is terminated and its disk deleted |
| Location | US regions in Virginia and the Midwest |
| Certifications | Not SOC 2 or HIPAA certified |
| Reserved builds | Your requirements in the brief, configuration and terms in writing |
Each instance is its own virtual machine#
Every QuantaCloud instance is a separate virtual machine. It boots from the same base image, Ubuntu 22.04 with the NVIDIA driver and Docker, and gets its own local disk, sized by the configuration and included in the hourly price. The Bare Metal template is the plain VM, and the app templates run one container on top of it (templates). Physical, single-tenant servers are a dedicated build, not an on-demand option. On-premise LLM compares the four places a model can run, from someone else's API to servers in your own building, and where your prompts go in each.
Each instance has a public IP address, and what runs on it is yours to configure, update and secure, as on any server.
My rule for anything you install: keep services on 127.0.0.1 and reach them through an SSH tunnel, or put TLS and authentication in front of what you open. Docker publishes ports past ufw, which running Docker with a GPU explains, and the SSH guide sets up the tunnel.
SSH access with your keys#
You log in over SSH as ubuntu on port 22 with a key pair. QuantaCloud generates a managed key pair for your account at sign-up and preselects it when you deploy, and its private key can be downloaded once. You can also upload your own Ed25519 or RSA public key, or generate a new pair whose private key downloads once. ECDSA keys are not installed on instances.
The option I recommend is your own key: create it on your laptop with ssh-keygen -t ed25519 and upload only the public half, so the private key never leaves your machine (SSH keys in the docs). Deleting a key from your account stops it being offered for new deployments, but it stays on instances that are already running. Through the API, a deploy request without ssh_key_ids installs every key on your account, so name the ones you want.
Browser apps sit behind your login#
App templates (PyTorch + Jupyter, Open WebUI + Ollama and ComfyUI) open at a private *.app.quantacloud.net URL. The URL asks for your QuantaCloud login, and only the account that owns the deployment can open it. JupyterLab and ComfyUI need no second password, while Open WebUI adds its own sign-in, where the first account becomes its admin. The URL stops working when the deployment stops.
API keys#
API keys start with gpu_live_, are shown once when you create them, and stop working the moment you revoke them. The API at core.quantacloud.net/api/v1 accepts a key as a Bearer token or in an X-API-Key header, and only the public catalog routes, such as offers and GPU families, answer without one. The API Keys page lists each key's name, prefix and the last time it was used, which makes stale keys easy to spot (API keys in the docs). Requests are limited to 3,000 per 15 minutes per IP address.
Resources are scoped to your account. A deployment or SSH key that is not yours returns not_found, and a deploy request that names another account's SSH key is rejected with invalid_ssh_key before anything is created or charged.
A key stored on an instance outlives the instance. Deleting the disk deletes the file, not the key, so revoke any key you put on a VM once you are done with it.
Your account#
You sign in with an email and password, with GitHub or Google, or with a one-time link sent by email. Sign-up, sign-in links and password resets are protected by a Cloudflare Turnstile challenge, and linking GitHub or Google to an account created with a password asks for that password once. Accounts are single-user: there are no team or organization accounts, so each person has their own login, keys and balance.
Deleting your account terminates every running deployment immediately and cannot be undone. The privacy policy covers what this website and its contact form collect.
What happens to your data#
Stopping an instance terminates it and deletes its disk. There are no volumes, no snapshots and no way to pause an instance and keep its disk, so nothing on it survives the end of a deployment.
| Event | What happens to the disk |
|---|---|
| You stop the deployment, in the console or through the API | Deleted with the instance |
| Your balance cannot cover the next hour | Deleted with the instance, with no grace period |
The deployment shows interrupted after a host failure or a failed health check | Treat it as lost |
| You delete your account | Every running deployment is terminated, disks included |
For data protection this cuts both ways: the disk is deleted when the deployment ends, and so is anything you did not copy off. Copy results off before every stop, and turn on auto top-up for anything that runs unattended, because the billing rules on the pricing page end an instance the moment its next hour cannot be paid (data persistence in the docs).
Where instances run#
On-demand instances run in data centers in the United States, in four regions: us-east-1 in Virginia, and us-midwest-1, us-midwest-2 and us-midwest-4 in the Midwest. The region you pick on the deploy page is where the instance and its disk physically are.
Payments#
Card payments go through Stripe. A new card is entered on Stripe's checkout page, and a saved card is charged from the Billing page.
Certifications and commitments#
QuantaCloud is not SOC 2 or HIPAA certified. If your contracts or regulators require a certified processor, an on-demand instance does not meet that requirement today. QuantaCloud does not publish an SLA either.
For account questions, email support@quantacloud.net or use the ticket form in the console.
Reserved builds#
A reserved build is quoted to your requirements, security included. We order and build the hardware to your spec, so where it runs, who can reach it and how data is handled are settled in the written quote rather than fixed defaults. Put your requirements in the brief: data location, access, encryption, audits and the questionnaires your team has to complete.
Send a capacity brief with your security requirementsReserved capacity explains how a build is quoted, and About QuantaCloud covers the company.
Security questions#
Is QuantaCloud SOC 2 or HIPAA certified?
No. QuantaCloud holds neither certification today.
Is my data deleted when I stop an instance?
Yes. Stopping terminates the instance and deletes its disk, and a deleted disk cannot be recovered.
Where is my data stored?
Data on an instance stays in the US region you pick, in Virginia or the Midwest, and only for as long as the instance runs.
Can I keep data between instances?
Not on QuantaCloud's on-demand instances. There are no volumes or snapshots, so keep code in Git and data in storage you control, and copy results off before you stop.
My rule for sensitive data on an on-demand instance: bring your own SSH key, keep services on 127.0.0.1, keep the master copy of the data off the VM, and stop the instance when the job ends, because the stop is what deletes the disk. If your security review asks for more than an on-demand instance offers, put it in a capacity brief: a reserved build is built to your spec, and its configuration and terms come back in writing.
Send a capacity brief