Docker is a workhorse. It’s also opinionated about the kind of environment it wants. It expects you can install system packages, run a background daemon, manage users and permissions, and keep state in a predictable place. That’s why a virtual machine (VM) is the clean path on Compute when your workflow depends on Docker.
If you’re still deciding between runtimes, read this first: [[Interlink: VM or container: how to choose in 60 seconds]]. If you want the short announcement and the “what changed” overview, start here: Compute now supports virtual machines (VMs).
Why Docker fits better on a VM
A container instance is designed to run your workload inside a managed environment. That’s perfect when you’re running a single app, a script, or a standard model setup. It gets awkward when Docker itself becomes part of the environment.
A VM gives you the missing pieces: sudo access, system packages, services, and the “this behaves like a normal Linux host” baseline that Docker expects. For most teams, that means less time on workarounds and fewer surprises later.
When you actually need Docker
Use Docker on a Compute VM when you’re doing any of the following:
- You want Docker Compose for multi-service stacks (API + worker + Redis + UI), and you want it to behave the same way it does on your laptop or on a traditional cloud VM.
- You’re packaging an ML workflow as a set of containers, and you want to keep it consistent across dev, staging, and production.
- You’re running tooling that assumes Docker exists (some internal build scripts, CI jobs, or platform tooling).
If your goal is simply “run one workload,” skip Docker and use a Compute container instance. It’s usually simpler. VM or container: how to choose in 60 seconds
What you need before you start
You only need two things to get going:
- An SSH key, so you can connect to the VM.
- A rough sense of what you want to run (a single container, a Compose file, or a repo that includes Dockerfiles).
If you already have a Compose stack, this is a good moment to note which ports it needs. You’ll use that in the Connectivity settings when you create the VM. If you don’t know yet, keep things closed and open ports later when you’re ready.
Launch a VM that’s ready for Docker
In the console:
- Click Create, then choose Virtual machine.
- Pick your location and hardware (GPU or vCPU).
- Pick an OS. If you don’t have a preference, Ubuntu is usually the least surprising choice for Docker-first workflows.
- Under Connectivity, add your SSH public key.
- Create the VM, wait for it to reach Running, then connect via SSH from the instance page.
If you want the canonical “click-by-click” reference, use: Compute quickstart or Launch and connect to your first Compute instance.
Install Docker and do a quick sanity check
Use this guide for the exact install steps on Ubuntu, Debian, or Fedora: Install Docker on a Compute VM.
Once Docker is installed, you can treat your VM like any other Docker host: pull images, run containers, and use docker compose for stacks.
Expose the right ports, and only the right ports
A common failure mode is “it runs, but I can’t reach it.”
When that happens, check two things:
- Your container is actually listening on the port you think it is (inside the VM).
- You’ve made that port reachable from outside (Connectivity settings or SSH port forwarding).
If you want the plain-English version of “SSH vs HTTPS vs TCP vs UDP,” use this: SSH, HTTPS, TCP, UDP: how to expose a service from a Compute VM. If you’re forwarding a local port to use a web UI, this doc is the reliable reference: How to forward ports to reach your web app.
Common questions
Can I run Docker on Compute?
Yes. Use a virtual machine. A VM gives you the OS-level control Docker expects. VM or container: how to choose in 60 seconds
Do I need Docker to run containers on Compute?
No. If you just want to run a single workload, a Compute container instance is usually the simplest route. Docker becomes useful when you need multi-service stacks, Compose, or tooling that assumes Docker exists.
What if I started with a container instance and now I need Docker?
That’s a normal path. Create a VM with the same region and hardware class, redeploy your workload, and treat it as a “graduation” to OS-level control. When it’s worth switching from a container instance to a VM
Try it on Compute
If Docker is part of how you ship work, don’t fight your runtime. Launch a VM, install Docker once, run your stack, and keep moving.
