Virtual machines vs containers

Two different boundaries

A hypervisor (FastNode runs VMware ESXi under vSphere) uses the CPU's hardware virtualisation extensions to run complete guest operating systems, each with its own kernel, memory map and virtual devices. The guest believes it's a computer.

Containers are ordinary Linux processes fenced in by kernel features: namespaces give them their own view of process IDs, mounts, network and users; cgroups cap CPU, memory and I/O; seccomp and capabilities trim the system calls they can make. Every container on a host shares that host's kernel.

So the question is rarely "which one?" It's "which boundary do I need, and where?"

Comparison

Why providers sell VMs, not containers

When strangers share hardware, the boundary between them needs to be as hard as practical. A hypervisor exposes a narrow interface to guests: virtual CPUs, memory and a handful of devices. A shared kernel exposes hundreds of system calls, any of which might have a bug. That's why FastNode gives each customer a VMware virtual machine rather than a container on a shared kernel.

It also means you get capabilities that container hosting often blocks: your own firewall with nftables, WireGuard as a kernel module, custom sysctls for network tuning, swap configuration, and the freedom to run Windows Server 2025 instead of Linux.

Why you'll probably run containers anyway

Inside your server, containers solve application problems well. They pin dependencies, make deployments repeatable and let you run several services on one machine without them stepping on each other's libraries. The common pattern on a VPS:

# Debian 12 example: Docker from the official repository
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/debian bookworm stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update && sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Here, the hypervisor separates you from other customers, and containers separate your services from each other. Each layer does the job it's good at. The Docker Compose production guide covers the rest of the setup.

Gotchas when you stack them

• Docker and host firewalls. Docker writes its own packet filter rules and can publish ports past a host firewall you thought was closed. Bind published ports to 127.0.0.1 behind a reverse proxy, or filter in the DOCKER-USER chain. Portal firewall rules sit outside the server entirely and aren't affected.
• Memory limits. Containers without limits can push the guest into its own out-of-memory killer. Set mem_limit or deploy.resources per service.
• Disk usage creeps. Old images and build cache accumulate. docker system df shows the damage; prune on a schedule.
• Nested virtualisation. Running full VMs inside your VM is a different matter from containers and shouldn't be assumed. Containers need no special support.

When containers alone are enough

If you control every workload on a host and trust them equally, such as one team's microservices, containers on a single machine are efficient and fine. If you're hosting code from people you don't trust, such as customers' builds on a CI runner, give each trust domain its own VM. A CI fleet split across several small servers is safer than one large runner executing everyone's jobs side by side; see CI runners.

Ready to build? Pick an image from the image list and a size from pricing, or read Docker hosts for sizing advice.