The error messages a rented GPU throws often look generic, but the causes on DeployGPU are specific: a login user that changes by provider, a status that reads Running before SSH is actually listening, a disk that is a fixed size chosen at launch. This section matches the exact text on your screen to the cause that is actually likely here, with the command to check it and the fix.
Start with what you see
| What you see | Usually means | Where to look |
|---|---|---|
Permission denied (publickey) | The username, key file or key type is wrong for this launch | Permission denied (publickey) |
Connection refused or a timeout right after launch | The status reads Running before SSH is actually listening, or the instance is gone | Connection refused |
No space left on device | The fixed disk filled with Docker images, model weights or caches | No space left on device |
REMOTE HOST IDENTIFICATION HAS CHANGED or Host key verification failed | A relaunched VM reuses an IP address your computer has seen before | Host key verification failed |
Failed to initialize NVML: Driver/library version mismatch | The NVIDIA driver was updated while the old one is still loaded | NVML driver/library version mismatch |
Torch not compiled with CUDA enabled | A CPU-only PyTorch build, or a different Python environment | Torch not compiled with CUDA enabled |
CUDA out of memory | Another process holds the GPU, or the job is too big for the card | CUDA out of memory |
Ollama answers slowly and ollama ps shows CPU | The model and its context do not fit in GPU memory | Ollama not using the GPU |
| Open WebUI loops on sign-in or lists no models | The wrong DeployGPU account, or nothing pulled yet | Open WebUI connection and sign-in problems |
| A job uses the wrong GPU on a multi-GPU VM | GPU numbering or CUDA_VISIBLE_DEVICES | CUDA_VISIBLE_DEVICES |
| An app link returns 403 or asks you to sign in again | Signed in as another account, or the deployment stopped | The app link problems page in the docs |
| A deployment fails before it ever reaches Running | A capacity or provisioning problem, reported with a failure code and refunded automatically | The deployment failures reference, or handling provisioning failures if you launch through the API |
Who is likely responsible
Some of this is DeployGPU's own doing, some is the provider underneath, and some is a command or a setting you chose. A wrong SSH username comes from the provider's own image, not from DeployGPU. A disk that filled up is on whatever you installed on it. A deployment that fails with a code such as PROVIDER_CAPACITY means the provider had no capacity for that offer at that moment, and the reserved hour is refunded automatically. Knowing which one you are looking at saves a support ticket that could not have fixed it anyway.
When to contact support
Contact support when a deployment is stuck in a state the dashboard cannot explain, when a charge does not match what the pricing page describes, or when none of the pages here match what you are seeing. The contact page is the way in, and the SSH guide is worth reading before the next launch rather than after.