Compute now lets you choose what kind of instance you want to run: a container or a virtual machine (VM). That choice matters, because it changes how much control you get over the environment and how much setup work you’ll do yourself. If you’ve ever thought “I just want this thing to run,” you’ll like containers. If you’ve ever thought “I need a real Linux box,” you’ll like VMs.
If you want the quick context on what changed in the product, start here: Compute now supports virtual machines (VMs). Then come back and pick the right runtime.
What you’re choosing, in plain English
A container is a lightweight runtime that shares the host operating system. It’s built to start fast and run an app or service with minimal fuss. On Compute, containers are the default choice for most workloads because they’re efficient and easy to repeat.
A virtual machine is a full Linux environment with OS-level control. It behaves like a server you can shape to your workflow. If you need system services, sudo, or tooling that expects a traditional machine, a VM is usually the cleaner option.
The 60-second decision
Choose a container if you want the simplest path to running a workload and you don’t need to manage the operating system. Containers are a good fit when your work looks like “run this app,” “serve this model,” or “spin up a standard environment and get going.”
Choose a VM if you need OS-level control or you keep running into environment limits. If the words “I need sudo,” “I need Docker,” or “I need a service that runs like it does on a normal server” show up in your notes, stop fighting it and launch a VM.
Here’s the practical checklist I’d use:
If any of these are true, lean VM.
- You need sudo access to install system packages or change how the machine is configured.
- You want to run Docker the normal way (including multi-service stacks), without workarounds.
- You’re setting up a long-running service that expects a classic Linux server shape, with system services and background processes.
- You care about stronger isolation boundaries between workloads and tenants, and you’d rather trade a bit of simplicity for that separation.
- You’re doing benchmarking or performance testing and want the environment to be consistent run to run.
If these are true, lean container.
- You want fast startup and a repeatable environment with less OS maintenance.
- Your workload fits a template or a standard container setup and doesn’t need system-level changes.
- You’re running a single service (an inference server, a script, a notebook-like workflow) and you want fewer moving parts.
A few common scenarios
You’re hosting an inference endpoint and you want it up quickly. Start with a container. It tends to be the fastest route to “running,” and you can keep your setup simple.
You’re building a pipeline that uses multiple services that expect Docker, or you’re trying to reproduce a known server setup from another cloud. Start with a VM. It’ll feel familiar, and you’ll spend less time translating assumptions.
You’re experimenting and you don’t yet know what the workload will demand. Start with a container, because it’s cheaper in time and attention. Switch to a VM as soon as you hit OS-level needs. Learn more: When it’s worth switching from a container instance to a VM
You want a deeper “what is a GPU VM and who needs it” explainer. This one is built for that: GPU virtual machine: what it is and who actually needs one.
If you’re operating under stricter security or data residency requirements, this is also worth reading: When sovereign AI workloads call for VMs.
If you picked “wrong,” nothing breaks
This is the part people overthink. You’re not signing a contract with your runtime.
If you start with a container and you later need OS-level control, you can move the workload to a VM. Most of what you’ve learned still applies: region choice, hardware choice, connectivity, and the way you think about starting and stopping. The main difference is that a VM gives you a fuller operating system to work with.
How to try both in the console
Open Compute, click Create, and choose either Container or Virtual machine. If you want to make the decision with minimal risk, start small, confirm your workflow, and scale up once you know what you actually need.
For step-by-step help connecting over SSH, this doc is the reliable reference: Launch and connect to your first Compute instance. If you want the short “get running fast” page, use: Compute quickstart.
