What is Docker?

Docker is an open platform for building, shipping, and running applications inside lightweight, isolated units called containers. A container bundles your code together with its runtime, system libraries, and configuration, so the software behaves identically on a laptop, a CI runner, and a production cluster. This is the practical answer to “but it works on my machine.”

Why Docker exists

Before containers, teams shipped applications onto servers that were hand-configured and slowly drifted apart. Dependency conflicts, mismatched runtime versions, and brittle deployment scripts were the norm. Docker standardizes the unit of delivery: you package the application once as an image and run that exact image everywhere.

The benefits compound quickly:

• Reproducibility — the same image runs the same way in every environment.
• Density — containers share the host kernel, so you run many more per machine than VMs.
• Speed — containers start in milliseconds, enabling fast scaling and ephemeral CI jobs.
• Portability — any host with a container runtime can run your image.

Containers vs virtual machines

Both technologies isolate workloads, but they operate at different layers. A virtual machine virtualizes hardware and runs a full guest operating system. A container virtualizes the operating system and shares the host kernel, isolating only the process tree, filesystem, and network.

Aspect	Container	Virtual Machine
Isolation level	OS / process	Hardware
Guest OS	Shares host kernel	Full guest OS per VM
Startup time	Milliseconds	Seconds to minutes
Size	Megabytes	Gigabytes
Density per host	High (hundreds)	Low (tens)
Overhead	Minimal	Hypervisor + OS

        VIRTUAL MACHINES                      CONTAINERS
  +------+ +------+ +------+           +------+ +------+ +------+
  | App  | | App  | | App  |           | App  | | App  | | App  |
  +------+ +------+ +------+           +------+ +------+ +------+
  | Bins | | Bins | | Bins |           | Bins | | Bins | | Bins |
  +------+ +------+ +------+           +------+ +------+ +------+
  |GuestOS||GuestOS||GuestOS|          +---------------------------+
  +------+ +------+ +------+           |     Docker Engine         |
  |        Hypervisor       |          +---------------------------+
  +-------------------------+          |        Host OS Kernel     |
  |        Host OS          |          +---------------------------+
  +-------------------------+          |        Hardware           |
  |        Hardware         |          +---------------------------+
  +-------------------------+

Containers are not a replacement for VMs in every case. They are complementary — many production platforms run containers inside VMs to combine kernel-level isolation with process-level packaging.

The image, container, and registry model

Three concepts form the core of Docker’s mental model.

• Image — a read-only template containing your application and its dependencies, built in layers. Images are immutable and versioned with tags such as nginx:1.27 or myapp:2.3.0.
• Container — a running (or stopped) instance of an image. It adds a thin writable layer on top of the image’s read-only layers. You can start many containers from one image.
• Registry — a store for images. Docker Hub is the public default; teams also run private registries such as Amazon ECR, GitHub Container Registry, or Harbor.

The everyday workflow ties them together:

docker pull nginx:1.27        # fetch an image from a registry
docker run -d -p 8080:80 nginx:1.27   # start a container from it
docker push myapp:2.3.0       # publish your own image to a registry

In short: you build an image, push it to a registry, then pull and run it as a container wherever you need it. The next page walks through installing Docker so you can try this yourself.