"But it works on my machine." Every developer has said it, or suffered because someone else did. An app runs perfectly on a laptop, then breaks on the server because of a missing library, a different OS version, or a config file nobody knew existed. Docker exists to end that conversation: it packages your app with everything it needs, so it runs the same everywhere, every time.
Docker's own docs describe Docker as "an open platform for developing, shipping, and running applications." That one sentence hides a decade of engineering that quietly reshaped how software gets built. Here is what Docker is, how containers differ from virtual machines, and why developers adopted it so fast.
Key Takeaways
Docker packages an app with all its dependencies into a container that runs the same on your laptop, a server, or the cloud, ending "works on my machine" problems.
A container is an isolated process sharing the host OS kernel, so it starts in seconds and uses far fewer resources than a virtual machine with its own full OS.
A Docker image is a read-only template built from a Dockerfile; Docker Hub is the world's largest registry for sharing images (Docker, retrieved 2026-10-22).
Docker Compose lets you define and run a whole multi-container app (app + database + cache) from a single YAML file with one command.
Adoption is near universal: Docker jumped 17 percentage points in a single year to 71% usage in Stack Overflow's 2025 Developer Survey (over 49,000 respondents).
What Docker Actually Is
Docker follows a client-server architecture. The `docker` client you type commands into talks to a long-running process called the Docker daemon (`dockerd`), which does the heavy lifting: building, running, and distributing containers. They communicate using a REST API over UNIX sockets or a network interface (Docker, updated 2026-09-07).
Docker is written in the Go programming language and leans on Linux kernel namespaces to carve out the isolated workspace that a container runs in. That isolation is the whole trick: each container believes it has its own filesystem, network, and process space, while actually sharing the host's kernel underneath.
For most beginners the entry point is Docker Desktop, the app for Mac, Windows, or Linux that bundles the daemon, the client, Docker Compose, Kubernetes support, and a credential helper in one installer. On licensing: Docker Desktop is free for personal use, education, non-commercial open source projects, and small businesses (fewer than 250 employees and less than $10 million in annual revenue); larger organizations need a paid subscription, while the open-source Docker Engine and Moby projects keep their existing terms unchanged (Docker, updated 2026-09-28).
Containers vs Virtual Machines
Before Docker, the standard way to isolate software was the virtual machine (VM). A VM emulates entire hardware and boots a full guest operating system: its own kernel, drivers, programs, and applications, just to isolate one app. As Docker's docs put it, "spinning up a VM only to isolate a single application is a lot of overhead."
Containers take the opposite approach. A container is an isolated process that shares the host OS kernel instead of booting its own OS. IBM's container docs describe it well: "A container is an app that is packaged with all its dependencies so that the app can be moved between environments and run without changes. Unlike virtual machines, containers don't virtualize a device, its operating system, and the underlying hardware."
Aspect | Container | Virtual Machine |
|---|---|---|
Detail | Shares the host OS kernel; packages only the app, runtime, libraries, and settings | Boots a full guest OS with its own kernel, drivers, and programs |
Startup | Seconds | Minutes |
Size | Megabytes | Gigabytes |
Density | Many more run on one host at once | Fewer per host because of the OS overhead |
Portability | "The container that runs on your development machine will work the same way in a data center or anywhere in the cloud" (Docker) | Portable as a disk image, but heavier to move |
The two technologies are not enemies. Cloud providers routinely run VMs as the provisioned machines and pack many containers inside each one, increasing resource utilization (Docker). Red Hat notes one limitation worth knowing: a VM can be migrated between hosts while still running, but a container must be stopped before it moves.
How a Container Gets Built: Images, Dockerfiles, and Registries
Three concepts carry the whole Docker workflow: images, Dockerfiles, and registries.
An image is, in Docker's words, "a read-only template with instructions for creating a Docker container." You build your own image by writing a Dockerfile, a plain text file where each instruction creates one layer of the image. When you rebuild, only the layers that changed get rebuilt, which is what keeps images small, lightweight, and fast to ship (Docker).
A container is simply a runnable instance of an image. You can create, start, stop, move, or delete it using the Docker API or CLI. The mental model is familiar: the image is the class, the container is the object; the Dockerfile is the recipe, the image is the cake, the container is a slice you actually serve.
To share images, you push them to a registry, "a place to store, retrieve, and share container images" that can be public or private (IBM). The biggest one is Docker Hub, which Docker calls "the world's largest container registry" (Docker, updated 2026-09-03). It offers unlimited public repositories, private repositories, webhooks, GitHub and Bitbucket integrations, and automated builds. The free Docker Personal plan allows unlimited public repos, one private repository, and 100 image pulls per hour for logged-in users (docker.com, 2026-08-19). Modern Docker Hub also stores more than images: Helm charts, SBOMs, digital signatures, provenance data, vulnerability reports, and even large language models live there now.
Docker Compose: One File, One Command, Whole Stack
Real apps are rarely one container. A typical web app needs the app itself, a database, and maybe a cache or message queue. Docker Compose is the tool for that: "a tool for defining and running multi-container applications" (Docker, updated 2026-05-28).
You describe the services, networks, and volumes of your entire stack in a single YAML file, then run everything with one command. Compose also handles the lifecycle: start, stop, and rebuild services, check running status, stream logs, or run one-off commands. It works the same in development, testing, staging, and production, which means the Compose file you run on your laptop is the same stack shape that ships to the server. That symmetry is a big part of why teams adopted it.
A Short History: From dotCloud's Internal Tool to Industry Standard
Docker started as plumbing, not a product. In 2013, a company called dotCloud, founded by Solomon Hykes in France before he relocated to the San Francisco Bay Area in late 2010 to raise funding, open sourced its internal container technology under the Docker nameplate (The New Stack).
The open-source release caught fire. Docker grew from a single project into what Hykes calls "a constellation of many different projects, including containerD, LinuxKit, SwarmKit, and the Moby Project." containerD, the core container runtime, was eventually donated to the Cloud Native Computing Foundation, and Kubernetes made it the default way to run containers in orchestration at scale. That ecosystem effect is why Docker stopped being just a tool and became infrastructure.
Why Developers Love It: The Adoption Story
The clearest evidence of Docker's impact is how fast the whole industry standardized on it. Stack Overflow's 2025 Developer Survey, its fifteenth annual edition with over 49,000 responses from 177 countries covering 314 technologies, found that "Docker has moved from a popular tool to a near-universal one. After years of growth, it experienced a +17 percentage point jump in usage from 2024 to 2025 (71%) among all cloud development and infrastructure technologies, followed by npm (57%) and AWS (43%)." (Stack Overflow, announced July 29, 2025).
That jump happened because containers solve problems developers feel daily:
Reproducibility. The container carries its dependencies, so staging matches production and onboarding a new teammate means running one command instead of a half-day setup guide.
Speed. Starting a container takes seconds, so the inner dev loop, test, change, rerun, stays fast.
Density and cost. More containers fit on one host than VMs would, which is why cloud bills got smaller for the same workloads (Red Hat).
Ecosystem. With Docker Hub's millions of public images, you almost never start from scratch: official images for Python, Node, Postgres, Redis, and nearly every tool are one `docker pull` away.
If you want to see what developers actually build and ship with containers, the short repo signal videos on RepoManiac regularly surface container-based open source projects worth a look.
Frequently Asked Questions
Is Docker free to use?
The open-source Docker Engine is free. Docker Desktop, the all-in-one app, is free for personal use, education, non-commercial open source projects, and small businesses (fewer than 250 employees and less than $10 million in annual revenue). Larger organizations and government entities need a paid subscription (Docker).
Does Docker replace virtual machines?
Not exactly. Containers are lighter and start faster, but VMs provide stronger isolation because each one runs its own kernel, and live migration between hosts is a VM-only trick. In practice the two are combined: VMs provide the machines, containers pack the apps onto them (Docker).
Do I need Docker Desktop, or can I use just the engine?
On Linux you can run the Docker Engine directly with no desktop app. On Mac and Windows, Docker Desktop (or an alternative) provides the Linux VM the engine needs under the hood. For learning and side projects, the free Desktop tier is the simplest start.
Is Docker hard to learn?
The basics are genuinely simple: one Dockerfile, one `docker build`, one `docker run`. The learning curve arrives later, with networking, volumes, multi-container Compose setups, and production orchestration. Start with a single container and grow from there.
The Bottom Line
Docker turned "it works on my machine" from a punchline into a solvable problem: package the app with its dependencies, share the host kernel instead of booting an OS, and run the same container everywhere. From a dotCloud internal tool open sourced in 2013 to 71% of cloud developers in 2025, containers won because they are fast, light, and repeatable. If you have never run one, pull an official image, run it, and watch a whole app start in seconds. That first `docker run` is usually the moment it clicks.
*Read this article in Indonesian: Docker Dijelaskan: Apa Itu Container dan Mengapa Developer Menyukainya.*