The difference between a GPU VM and a container pod is the kernel: a VM boots its own, a container borrows the host's, and most of the limits people meet with Docker Compose, systemd or Docker-in-Docker follow from that one fact. DeployGPU facts below were checked on 1 October 2026, and the container facts come from Docker's and Vast.ai's own documentation, checked the same day.
What Docker says a container is
Docker's what is a container page describes containers as isolated processes that share the host's kernel, and a VM as a whole operating system with its own kernel, drivers and programs. So a container holds your processes, and anything that needs the kernel or the init system belongs to the host. That is why a container is quick to start, and why it cannot do everything a machine can.
Vast.ai's documentation draws the same line inside one product. Its virtual machines page says VM instances give a complete Linux environment for workloads that need init managers such as systemd, or nested containers, and lists the price: slower creation and boot times, more disk overhead, fewer machines and fewer templates.
Seven differences that matter for GPU work
| You want to | On a GPU VM | In a container pod |
|---|---|---|
| Run Docker or Compose | Docker comes with the images the DeployGPU dashboard picks | Compose needs a Docker daemon, and Docker's image documentation says running one inside a container needs --privileged, which a platform may not grant |
| Run systemd services | The VM has its own init system | Vast.ai lists systemd support as something its VM instances add over its containers |
| Choose the driver | Pick the provider's OS image, which carries a driver | The host's driver comes with the machine you land on |
| Open ports | Any port, but DeployGPU does not firewall VMs, so bind to 127.0.0.1 and tunnel over SSH | Usually the ports the platform maps, and SSH may go through a proxy |
| Administer the machine | root on Verda, ubuntu or Ubuntu on the others, and the commands on this site use sudo | Usually root inside the container only, with the host kept by the platform |
| Keep files | The instance disk, fixed per offer on three providers and up to 500 GB on Verda, is deleted when you stop. Volumes exist on Verda and Hyperstack only | Set by the platform, so read what survives a restart |
| Start time | 1 to 3 minutes to Running | Faster, going by Vast.ai's own list of what VMs cost |
On a VM you can see the driver with nvidia-smi and pick a CUDA image tag at or below the version it shows. On a container platform, the host you land on fixes the driver, and with it the newest CUDA image that will start.
How DeployGPU labels its five providers
| Provider | What you get | Launch from | SSH |
|---|---|---|---|
| QuantaCloud | VM | Dashboard and API | ubuntu, port 22 |
| Massed Compute | VM | Dashboard and API | Ubuntu, port 22 |
| Hyperstack | VM | Dashboard and API | ubuntu, port 22 |
| Verda | VM | Dashboard and API | root, port 22 |
| Vast.ai | Container | Dashboard only, labelled Testing Only | root, a proxy port shown in the dashboard |
In the API, every offer carries a deploymentType: virtual for the four VM providers and dedicated for Vast.ai containers. A create call against a dedicated offer returns provider_not_supported. Vast.ai bandwidth is billed separately from the hourly rate. Vast.ai also documents VM instances on hosts that support them, but DeployGPU's offers label its Vast.ai entries dedicated, so I treat them as containers here.
The app templates are containers inside a VM
Open WebUI + Ollama, ComfyUI and PyTorch + Jupyter each run one Docker container, named deploygpu-workload, on a GPU VM. You keep SSH into the VM underneath, so the container is yours to inspect:
sudo docker ps
sudo docker logs deploygpu-workload
sudo docker exec -it deploygpu-workload bash
To see which kind of machine you are on, ask for PID 1. On an Ubuntu VM it is systemd. Inside a container it is whatever process the container started:
ps -p 1 -o comm=
What a VM costs you
More to look after. DeployGPU does not firewall VMs, and Hyperstack VMs are created with inbound traffic open, so anything bound to 0.0.0.0 is on the internet. A VM also does not mean persistence: on DeployGPU, stopping deletes it and its disk, with no pause or snapshot. And it is not a bare metal server. The dashboard's Bare Metal label names a plain GPU VM, and each of the four VM providers launches a virtual machine.
When a container is the better call
A container wins when the job is one process serving one port from a prebuilt image. There is no operating system to look after, and the start is faster. DeployGPU's app templates give you part of that on a VM, because the app arrives already running in its container.
Which to pick
| If you need | Pick |
|---|---|
| Docker Compose, Docker-in-Docker or Kubernetes | A VM |
| systemd services | A VM |
| Several ports or your own firewall rules | A VM, behind an SSH tunnel |
| A specific OS image or driver | A VM |
| Launching from code | A VM, because the DeployGPU API launches VMs only |
| A quick try of a prebuilt image | Either, after you check the platform's limits |
My rule is to start with a VM whenever the job needs Compose, systemd or more than one open port, and to reach for a container when a prebuilt image already does everything and I want the fastest start.
Opens the deploy page on the cheapest 1x RTX A6000 offer at 2026-10-13 12:10 UTC: QuantaCloud, $0.48/hr. You can pick another GPU there before paying.
The GPU VM page walks through the first commands, the GPU containers guide shows how to run containers on the VM, and the providers page compares the five.
Frequently asked questions
Is a DeployGPU template a VM or a container?
Both. Each app template runs one Docker container on a GPU VM, and you keep SSH access to the VM underneath.
Can I run Docker Compose on DeployGPU?
Yes, on a GPU VM, because you administer the machine and Docker comes with the images the dashboard picks. Install the Compose plugin if the image does not have it.
Can I launch Vast.ai containers through the API?
No. The API launches VMs on QuantaCloud, Massed Compute, Verda and Hyperstack. Vast.ai entries are containers in the dashboard only, labelled Testing Only.
Does a VM start slower than a container?
Usually. A DeployGPU VM typically reaches Running in 1 to 3 minutes, and Vast.ai's documentation lists slower creation and boot times as a cost of its VM instances.
Does DeployGPU firewall my VM?
No. Bind services to 127.0.0.1 and reach them through an SSH tunnel, or run ufw yourself.