Docker containers vs virtual machines: which should run your application?
Most teams asking about Docker are deciding how to package and run an application: as containers on a shared host, or as virtual machines that each carry a whole operating system. The two are often used together, so the real questions are which workloads go where and what moving an existing application into containers involves.
Should your application run in Docker containers or virtual machines?
Quick answer
Docker containers vs virtual machines comes down to isolation. Containers share the host operating system kernel, so they start fast and pack densely; virtual machines run a full guest operating system on a hypervisor. Most new services fit containers, while other kernels, legacy software and host-bound licences need VMs. Agnotic Technologies maps each workload first.
| Criterion | Containers | Virtual machines |
|---|---|---|
| Operating system and kernel | Services built for the host's kernel; Windows containers need Windows hosts | Any guest operating system, including older or different kernels |
| State | Stateless processes, with data in managed databases or mounted volumes | Applications that keep state on local disk and expect the same server every time |
| Scaling pattern | Scale out by starting more identical copies in seconds | Scale up to a larger VM, or out more slowly from machine images |
| Isolation need | Process isolation on a shared kernel; give untrusted code its own VM or a sandboxed runtime | Separation enforced by the hypervisor |
| Licence terms | Confirm the vendor supports and licenses the product in containers | Fits licences counted per host, core or VM |
| Patching | Rebuild and redeploy the image; patch the host separately | Patch each guest operating system in place, or rebuild it from an image |
| Team skills | Image builds, registries and an orchestrator | Server administration and configuration management |
| Typical answer in a mixed estate | Containers for new and stateless services | VMs for the rest, and often as the hosts the containers run on |
What they are
What is Containers
A container packages an application with its libraries and runs it as an isolated process on the host. NIST SP 800-190 calls containers a form of operating system virtualization combined with application software packaging. Every container on a host shares its kernel, which makes containers quick to start and dense to pack.
What is Virtual machines
A virtual machine runs a complete guest operating system on virtual hardware provided by a hypervisor. NIST SP 800-125 describes full virtualization as running one or more operating systems and their applications on top of virtual hardware. Each VM has its own kernel, so workloads are separated below the operating system.
Key differences
How does each one isolate a workload?
Docker's documentation puts it plainly: a VM is an entire operating system with its own kernel, hardware drivers, programs and applications, while a container is an isolated process with the files it needs, and multiple containers share the same kernel. The Kubernetes documentation says containers have relaxed isolation properties to share the operating system among applications. A shared kernel is lighter and faster, and it also means a kernel flaw can reach every container on that host.
When is a VM still required?
Four cases appear in almost every estate. Software that needs another operating system or kernel version. Legacy applications that assume a full server with local files, scheduled tasks or a desktop session. Vendor products whose support terms name an operating system on a VM. And licences counted per host or core, where moving into containers can change what you owe. Check each one with the vendor before planning the move.
What does a container security baseline include?
NIST SP 800-190 explains the security concerns that come with containers and gives recommendations across images, registries, orchestrators, containers and host operating systems. In practice: scan images for vulnerabilities, use small base images, run as a non-root user, keep secrets out of images, pull only from a trusted registry and harden the hosts. The CIS Docker Benchmark gives consensus secure configuration guidelines for Docker to check against.
Do you need Kubernetes to run containers?
No. Kubernetes describes itself as a portable, extensible, open source platform for managing containerized workloads and services, and that power comes with operating work. One service can run on a single host with Docker Compose. A handful of services fit a managed container service from your cloud provider. Kubernetes pays off when you run many services, need custom scheduling or want one platform across environments.
Can containers and VMs run together?
They usually do. Docker's documentation notes that in a cloud environment the provisioned machines are typically VMs, and that a VM with a container runtime can run several containerized applications. Many estates keep databases and vendor software on VMs and move their own services into containers on VM hosts.
When to use each
When to use Docker containers
- New services and APIs built for Linux that you deploy often.
- Workloads that scale out by adding identical copies.
- Teams that want the same image in development, CI and production.
- Several small services that would each waste a whole VM.
When to use virtual machines
- Software that needs a different kernel or operating system from the host.
- Legacy applications that expect a full server, a desktop session or local state.
- Vendor products supported only on a named operating system in a VM.
- Licences counted per host, per core or per server.
- Workloads that need a hard isolation boundary from their neighbours.
What does containerizing an existing application involve?
Does it keep state on local disk? Move uploads, sessions and files to a database, object storage or a mounted volume first. Failure point: data written inside the container disappears when it restarts.
Are hostnames and credentials hard-coded? Read configuration from environment variables and secrets from a secrets store. Failure point: an image that only works on one server.
Is the image small and rebuilt often? Start from a minimal base image, build in stages and rebuild whenever the base image is patched. Failure point: oversized images that pull slowly and carry unused packages with vulnerabilities.
Does it run as a non-root user? Set a user in the image and drop privileges it does not need. Failure point: a compromised process holding root on a shared kernel.
Does it log to standard output and report its health? Containers are replaced, not repaired, so logs must leave the container and the orchestrator needs a health check. Failure point: logs lost with every restart.
Can it shut down cleanly? Handle the stop signal and finish in-flight work. Failure point: dropped requests on every deploy.
Is every third-party licence valid in containers? Confirm with each vendor. Failure point: a licence audit finding after the move.
Which sources does this comparison rely on?
- NIST SP 800-190: Application Container Security Guide (csrc.nist.gov)
- NIST SP 800-125: Guide to Security for Full Virtualization Technologies (csrc.nist.gov)
- Docker documentation: what is a container? (docs.docker.com)
- Kubernetes documentation: overview (kubernetes.io)
- CIS Docker Benchmark (cisecurity.org)