Containers vs virtual machines

Anyone hosting an app soon meets both terms: the VPS you rent is a virtual machine, and the platform that takes your code usually runs it in a container. They look alike, but they isolate in different ways, and that changes cost, security and maintenance work.

What is a virtual machine?#

A virtual machine (VM) is a computer simulated in software. A hypervisor divides the physical hardware and gives each VM virtual CPU, memory and disk. Inside runs a complete operating system, including the kernel, the core that talks to the hardware. Because it runs a whole operating system, a VM needs more CPU, memory and storage, according to Microsoft's documentation.

The result is a separate computer: you can install any compatible system, change drivers and open any port. In exchange, updating the system, configuring the firewall and keeping it secure become your job. This is the model covered in VPS vs cloud platform.

What is a container?#

In Docker's words, a container is an isolated process with all the files it needs to run. There is no second operating system: every container on a machine shares the same host kernel. Microsoft describes it as a lightweight, isolated silo that runs on top of the host kernel and holds only the app plus a few user-mode system APIs.

You can see this on a Linux host with Docker Engine installed directly (Docker Desktop runs containers inside a VM, so there the kernel shown is that VM's). Both commands below print the same kernel version, because the container has no kernel of its own:

uname -r
docker run --rm alpine uname -r

How does a container isolate without its own kernel?#

On Linux, isolation comes from two kernel features:

• Namespaces make a global resource look private to the processes inside the namespace. There are namespaces for mount points (mnt), process IDs (pid), networking (net), hostname (uts), users (user) and more. Inside the container, a process sees only its own processes, its own network and its own filesystem.
• Cgroups (control groups) group processes and limit and monitor their resource use, such as memory and CPU.

That is why you can cap a container when you start it:

docker run --rm -m 256m --cpus 1 alpine echo "capped at 256 MB and 1 CPU"

This isolation is real, but the same kernel enforces it for everyone. A serious bug in that kernel affects every container on the machine. With a VM, a flaw in the guest kernel stays inside that VM: to reach the others, an attacker would also have to escape the hypervisor.

Containers vs VMs side by side#

The table follows Microsoft's comparison for isolation, operating system and updates. There are variations: containers hardened by a lightweight VM, and containers running inside VMs (a common cloud setup).

When should you use a container?#

A container fits when the app is an ordinary process and you want to package and move it painlessly:

• bots, APIs and sites in Node.js, Python, Java and similar languages;
• identical development and production environments: the image carries the dependencies, which helps avoid "it works on my machine";
• several small services sharing one server;
• frequent deploys, where swapping an image is simpler than reconfiguring a machine.

Settings such as keys and database URLs stay out of the image, in environment variables, so the same image works in any environment.

When should you use a virtual machine?#

A VM is the choice when you need what a container cannot give:

• an operating system different from the host, such as Windows on a Linux server;
• kernel access: modules, drivers or system parameters;
• a strong security boundary between workloads that do not trust each other;
• software that expects a whole machine, administered by hand.

If you only want to keep one process running, a VM is usually more machine than you need. The two also combine: the VPS you rent can be the base of a Docker server. For the next step, see what deploy is.

How to do this on Square Cloud#

Square Cloud is self-service hosting built on containers. Each application runs in an isolated container in a Tier 3 datacenter in New York, always on with no sleep mode, and with automatic restart (on by default for dashboard deploys) when the process exits with an error. You do not administer an operating system: you deploy your code and set the application's RAM.

You can deploy by uploading a ZIP in the dashboard, with the CLI, through GitHub (a push triggers the deploy, via the official GitHub Action or a webhook) or with the VS Code extension. There are several runtimes, such as Node.js, Python, Java, Go and Rust: see the runtimes available today on Runtimes. Environment variables live in the dashboard, the API or the CLI and apply on the next restart, with no rebuild. To scale, you change the application's RAM (vertical scaling); there is no autoscaling.

There is no root access (the process runs as an unprivileged user) and no Dockerfile or custom image. If you need root, another operating system or kernel access, use a VM. If a container is enough, see what is included in Square Cloud features.