What Is Docker? The Docker Technology and Container Concept Explained

Docker is an open source platform for building, shipping and running applications in containers. A container is a package that holds your application together with everything it needs to run: the runtime, libraries, system tools and configuration. Because everything is inside that package, the application runs the same way on a developer’s laptop, a test server and in production.

In this article I explain the container concept and its most popular implementation, Docker. You’ll learn what a container is, where containers are stored, and how Docker changes the way we develop and deploy applications, with concrete before and after examples.

What is Docker used for?

Docker is used to package applications into containers and run them anywhere. In practice, that means three main use cases:

• Local development: start databases, message brokers and other services your app needs with one command each, without installing them on your computer
• Shipping applications: build your application once as a Docker image and use the exact same image in testing, staging and production
• Deployment and operations: run applications on servers, in the cloud or on Kubernetes without configuring each server for each application

Docker was released as open source in 2013, and since then containers have become the standard way to package and deploy software. If you work in DevOps, cloud or backend development, you will use Docker or containers almost every day.

What is a container?

A container is a way to package an application with everything it needs inside that package, including all its dependencies and all the necessary configuration. That package is portable, just like any other artifact, so it can easily be shared and moved between developers, or between development and operations teams.

The portability of containers, plus having everything packaged in one isolated environment, is what makes development and deployment so much more efficient. You’ll see concrete examples of that below.

Technically, a container is an isolated process running on a host machine. It has its own file system, network and process list, but it shares the host’s operating system kernel. That’s why containers are much smaller and faster than virtual machines. I explain the technical side in detail in What is a Docker container.

What is Docker containerization?

Containerization is packaging an application and its dependencies into a container image so it can run in isolation on any host. Docker is the tool that made containerization easy and popular: you describe your application’s environment in a Dockerfile, build an image from it, and run that image as a container with one command.

Containers existed in Linux before Docker, but they were hard to use. Docker added a simple command line, a standard image format and a public place to share images, and that is what made containerization mainstream. Today Docker isn’t the only container technology: tools like Podman and containerd can run the same images, because container images follow the open OCI (Open Container Initiative) standard. But Docker is still the tool most people learn first and use for building images.

How does Docker work?

Docker works with a client-server architecture. You type commands in the Docker CLI (the docker command), and the CLI sends them to the Docker daemon (dockerd), a background service that builds images, runs containers and manages networks and volumes. The daemon pulls images from and pushes them to registries like Docker Hub.

The basic Docker workflow has three steps:

1. Build: you write a Dockerfile with instructions, for example which base image to use, which files to copy and how to start the app, and run docker build to create an image
2. Ship: you push the image to a registry with docker push, so others and your servers can download it
3. Run: anyone with Docker runs docker run to start a container from that image

Here are the main parts of the Docker technology at a glance:

Component	What it is
Docker Engine	The core of Docker: the daemon (dockerd) plus APIs that build and run containers
Docker CLI	The docker command you use to talk to the Docker Engine
Dockerfile	A text file with instructions for building an image
Docker image	A read-only package with the app, its dependencies and configuration
Docker container	A running instance of an image
Registry	Storage for images, for example Docker Hub or a private registry
Docker Compose	A tool to define and run multi-container applications with one YAML file
Docker Desktop	An app for Windows and Mac (and Linux) that runs Docker Engine in a lightweight VM, with a GUI

Where are Docker images stored? Container registries

Since containers are portable, there must be some storage where you can share them and move them around. That storage is a container registry, and it stores container images (the package a container is started from). Each application has its own repository in the registry, with many versions (tags) of the image.

Private vs public registries

Many companies have private registries where they store the images of their own applications, for example Amazon ECR, Google Artifact Registry, Azure Container Registry, GitLab Container Registry or Nexus. Only people and servers with access can pull from them.

There is also the big public registry for Docker: Docker Hub. That’s where you browse and find images for almost any application you need.

For popular technologies like Postgres, Redis, Nginx, Node.js or Jenkins, there are Docker Official Images, maintained and reviewed together with Docker. You’ll also find many unofficial images made by other developers and companies. As a beginner, prefer official images or images from verified publishers, because you can trust where they come from.

The public registry is usually where you get started: you can find a ready image for almost any service your application depends on.

How does Docker make application development easier?

With Docker you don’t install the services your application needs directly on your operating system. You start each service in a container, with one command, and every developer on the team gets exactly the same setup.

How developers worked before containers

Let’s say your team develops a JavaScript application that needs PostgreSQL as a database and Redis for caching and messaging. Before containers, every developer had to install the binaries of these services, configure them and run them on their own computer.

The installation looks different depending on the operating system: Mac, Windows or Linux. And each service has multiple installation steps, so there are many chances for something to go wrong.

This process of setting up a new environment is tedious, depending on how complex your application is. If your application uses 10 services, every developer repeats that 10 times, on every machine, and the versions can easily end up different between team members.

How developers work with containers

With containers, you don’t install any of the services directly on your operating system. Each container is its own isolated environment, with a Linux base image, the service in the exact version you need, and its configuration and start script.

So as a developer, you don’t search for binaries to download. You find the image in a registry and start it with one Docker command, which pulls the image and starts the container at the same time:

docker run -d --name postgres -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 postgres:17
docker run -d --name redis -p 6379:6379 redis:7

The command is the same no matter which operating system you use. If your app needs 10 services, you run 10 Docker commands, or you put them all in one compose.yaml file and start everything with docker compose up. And you can even run different versions of the same application side by side without any conflict.

How does Docker improve application deployment?

With Docker, the development team ships one image that contains the application and its whole environment, and the operations team runs that image on the server. Nothing needs to be installed or configured on the server except Docker itself.

Deployment before containers

In a traditional deployment, the development team creates an artifact, for example a JAR file for a Java application, together with a textual guide on how to install and configure it on the server. Plus instructions for the database and other services the application needs.

The operations team then takes those artifacts and sets up the servers to deploy the application. This causes two typical problems:

• Dependencies installed directly on the server’s operating system: everything has to be installed and configured on the server itself, which can lead to version conflicts when several applications or services run on the same host
• Misunderstandings between teams: because everything is described in a text guide, developers can forget to mention an important configuration step. When the deployment fails, operations has to go back to the developers, and the back-and-forth continues until the application finally runs

Deployment with containers

With containers, developers and operations work together to package the application with all its configuration and dependencies into one image.

Because everything is already encapsulated in the image, you don’t need to configure anything for the application directly on the server. You run one Docker command that pulls the image from the registry and starts it. The only thing you need on the server is the Docker runtime, and that’s a one-time setup.

That is also why containers fit so well with CI/CD pipelines and with Kubernetes: a pipeline builds the image once, and the same image is deployed to every environment.

Frequently asked questions

What is Docker in simple terms?

Docker is a tool that packages an application and everything it needs into a container, so it runs the same way on any computer. Instead of installing software and its dependencies on each machine, you run one Docker command and the container starts with everything inside. It’s like shipping your app in a standard box that fits everywhere.

What is Docker technology used for?

Docker technology is used to build, ship and run applications in containers. Developers use it to set up local development environments quickly, teams use it in CI/CD pipelines to build and test applications, and operations teams use it to deploy applications on servers, in the cloud and on Kubernetes.

Is Docker the same as containerization?

Not exactly. Containerization is the general concept of packaging an application with its dependencies into an isolated container. Docker is the most popular tool for doing that, and it’s what made containerization mainstream. Other tools like Podman and containerd can run the same OCI container images.

Is Docker a virtual machine?

No. A virtual machine runs a complete operating system with its own kernel, while a Docker container is an isolated process that shares the host’s kernel. That’s why containers are much smaller and start in seconds. On Windows and Mac, Docker Desktop runs a small Linux VM in the background to provide the Linux kernel.

Is Docker free?

Docker Engine and the Docker CLI are open source and free to use. Docker Desktop is free for personal use, education, open source projects and small businesses, but larger companies need a paid subscription, so check Docker’s current terms for your situation. Docker Hub has a free tier with limits on private repositories and image pulls.

What is the difference between Docker and Kubernetes?

Docker builds images and runs containers on one machine. Kubernetes is a container orchestration platform that runs and manages many containers across a cluster of machines, with features like scaling, self-healing and rolling updates. You typically build images with Docker and run them in production on Kubernetes.

Where to go from here

Next, read What is a Docker container to see how containers work technically and how to run them, and What problem does Docker solve for the full list of problems containers fix. Then compare containers with VMs in Docker vs Virtual Machine, and learn to write production-ready Dockerfiles with my Docker best practices. All my Docker articles and guides are on the Docker topic page.