Docker: What is it and why is it important?

Docker is an open platform for developing, shipping and running applications in containers. It packages your code together with the libraries, tools and settings it needs, so the same application behaves identically on a laptop, on a build server and in production. That is the short answer to what Docker is.

The longer answer is why containers went from a niche Linux feature to the default unit of deployment for almost all modern software. This guide covers what Docker is and what a container actually is, why Docker is important, what you use it for, how to install it and run your first container, what it costs, where it causes problems, and how it compares to virtual machines and to alternatives like Podman.

What is Docker?

The formal definition is the one Docker itself uses. Docker is an open platform for developing, shipping, and running applications that enables you to separate your applications from your infrastructure. At its core, Docker provides containerization technology that packages software into standardized units called containers, which include everything needed to run an application: code, libraries, system tools, and runtime.

Unlike traditional virtual machines that require a complete operating system for each instance, Docker containers share the host operating system kernel while maintaining isolation between applications. That single design decision is why containers start in seconds rather than minutes, and why a single host can run dozens of them where it would struggle with a handful of virtual machines.

What is a Docker container?

A container is a running instance of a Docker image. The image is the read-only template: your application, its dependencies and its configuration, stored as a stack of filesystem layers. The container is what you get when you start that image, namely an isolated process with its own filesystem view, its own network interface and its own process tree, running directly on the host kernel.

Containers are disposable by design. Stop one, start another from the same image, and you get an identical environment. Anything you want to keep has to be written to a volume or to an external service. That surprises most people coming from virtual machines, and it is covered further down under volumes.

Is Docker a platform, a framework or a tool?

Docker is a platform, not a framework. A framework dictates how you write your application. Docker does not care which language, framework or architecture you use. It only requires that your application can be described as an image and started as a process.

It helps to separate the parts that people all refer to as “Docker”:

• Docker Engine is the runtime that builds and runs containers. Underneath it uses containerd, a CNCF graduated project, and runc, the Open Container Initiative reference runtime.
• Docker CLI is the docker command you type.
• Docker Desktop is the packaged application for Windows, macOS and Linux that bundles the Engine, the CLI, Compose, an optional Kubernetes cluster and a graphical interface.
• Docker Hub is the registry where images are stored, discovered and shared.
• Docker, Inc. is the company that maintains the commercial products, subscriptions and enterprise solutions.

Two of these features are worth separating in your head: the Docker CLI and Docker Desktop are convenience layers, while the Engine is the part that actually does the work. The container image format and runtime themselves are open standards under the Open Container Initiative. This is what makes Docker a safe default rather than a lock-in risk: an OCI image you build with Docker also runs on Podman, containerd, Kubernetes and every major cloud container service.

What is Docker Desktop used for?

Docker Desktop is what most developers actually install. On Windows and macOS it runs a small Linux virtual machine and gives you Docker Engine inside it, plus the CLI, Docker Compose, a single-node Kubernetes cluster you can switch on, image and container management screens, and a vulnerability view for the images you pull.

On Linux you do not need it. Docker Engine installs natively from the package repositories. Docker Desktop for Linux exists mainly for teams that want the same experience on all three operating systems.

Docker Desktop is free for personal use, education, open source projects and companies with fewer than 250 employees and less than 10 million US dollars in annual revenue. Above either threshold a paid subscription is required. Costs are covered below.

A short history of Docker

Docker was announced publicly by Solomon Hykes at PyCon in Santa Clara in March 2013, as an internal project of the platform-as-a-service company dotCloud. It was open sourced that same month, and version 1.0 shipped in June 2014. dotCloud later renamed itself Docker, Inc., and in 2019 it sold its Docker Enterprise business to Mirantis to focus on developer tooling, which is why the commercial products you see today centre on Docker Desktop and Docker Hub.

Containers were not new. Linux had control groups and namespaces, and LXC had existed for years. What Docker added was an image format, a public registry and a command line simple enough that ordinary developers could use containers without understanding kernel internals. That accessibility, rather than the underlying technology, is what changed the industry.

Why is Docker important?

Docker is important because it solved a specific and expensive problem: software that works in one environment and fails in another.

Before containers, deploying an application meant reproducing its environment by hand or through configuration management. Operating system version, library versions, environment variables, file paths and installed tooling all had to line up. They rarely did, and the gap between “it works on my machine” and “it works in production” consumed a large share of engineering time.

An image removes that gap by making the environment part of the artefact. The thing you tested is the thing you ship. Four consequences follow, and they are the reason Docker matters:

• Consistency. The same image runs on a laptop, in the CI pipeline and in production, with no environment drift in between.
• Speed and density. Containers share the host kernel, so they start in seconds and a single machine can run many of them.
• Portability. An OCI image runs on any compliant runtime and any cloud, without being rewritten or repackaged.
• Composability. Small, independently deployable services become practical to operate, which is what made microservices and later serverless container platforms viable.

The knock-on effect is that containers became an assumption rather than a choice. Kubernetes, GitHub Actions runners, most CI systems, most platform-as-a-service offerings and most AI inference stacks all take a container image as their input. Understanding Docker has moved from a specialisation to a baseline skill for developers, DevOps engineers and data teams.

What can you use Docker for?

Docker serves multiple purposes across the software development lifecycle:

Application deployment and scaling

Docker’s container-based platform allows for highly portable workloads that can run on a developer laptop, on physical or virtual machines in a data centre, or at a cloud provider. That portability makes it straightforward to move workloads and to scale applications up or down as demand changes, because adding capacity means starting more copies of an image rather than provisioning and configuring another server.

Development environment standardization

Docker eliminates the “it works on my machine” problem by ensuring consistent environments across development teams. Because the instructions for creating an environment live in a Dockerfile in version control, you can reduce inconsistencies between machines and get every team member working in the same setup. New joiners clone the repository and run one command instead of following a setup document that is always slightly out of date.

Continuous integration and delivery

Docker streamlines the development lifecycle by letting developers work in standardized environments using local containers. The same image that was built and tested in the pipeline is the one promoted to production, which removes an entire class of deployment failures. Most CI platforms, including GitHub Actions and GitLab CI, run their jobs inside containers by default.

Microservices architecture

Docker’s lightweight nature suits microservices architectures, where an application is decomposed into smaller, independently deployable services. Each service runs in its own container with its own dependencies, so teams can update, scale and roll back individual components without coordinating a single large release.

AI and machine learning workloads

AI projects have a dependency problem that containers are well suited to. CUDA versions, Python packages, model runtimes and system libraries have to match exactly, and reproducing that stack across a workstation, a training server and a cloud instance by hand is unreliable. An image pins the whole stack once.

Docker has also moved into this area directly. Docker Model Runner serves local language models behind an OpenAI-compatible API, so existing tooling can point at a model running on your own hardware instead of a cloud endpoint. The Docker MCP Catalog and MCP Toolkit distribute Model Context Protocol servers as containers, which removes the need to install a language runtime for every tool an AI assistant needs. Docker Sandboxes run coding agents inside isolated microVMs, a reasonable precaution when an agent has shell access to a machine.

How to get started with Docker

Getting started with Docker involves a few straightforward steps.

Installation

Docker is available as Docker Desktop for Windows and macOS, and as Docker Engine packages for Linux distributions. Compose is now part of the Docker CLI and is invoked as docker compose, not as the old docker-compose binary. On Windows, Docker Desktop defaults to the WSL 2 backend, with Hyper-V and Docker VMM as alternatives, so check that Windows and WSL meet the documented version requirements before installing.

How to install Docker?

Windows and macOS: install Docker Desktop, which includes Docker Engine, Buildx and Compose. Verify with docker --version and docker compose version in a terminal.

Linux (Ubuntu or Debian): install Docker Engine from Docker’s apt repository. The current packages are docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin and docker-compose-plugin, which replace the legacy standalone docker-compose binary.

Example Ubuntu steps, in a terminal with sudo privileges:

# Prerequisites
sudo apt update
sudo apt install -y ca-certificates curl
 
# Keyring
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
 
# Repository, in the deb822 format Docker now documents
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<SOURCES
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
SOURCES
 
# Install Engine, Buildx and the Compose plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Your first Docker container

Run a quick validation after installation. On Linux, prepend sudo unless your user has been added to the docker group.

sudo docker run hello-world

If that prints a welcome message, the Engine is installed, it can reach Docker Hub and it can start a container. Adding your user to the docker group removes the need for sudo, but note that this grants privileges equivalent to root on the host.

Understanding Dockerfiles

A Dockerfile is a text file containing the instructions for building a container image. It defines the base image, the files to copy, the dependencies to install and the command to run, which makes builds reproducible and automatable.

Choose a maintained base image. Running an end-of-life runtime is one of the most common sources of avoidable vulnerabilities in container images, so pin to a supported LTS major version rather than to a floating latest tag. Slim and Alpine variants cut image size significantly, and Docker also publishes Hardened Images built for a near-zero CVE count where that matters.

Example Dockerfile for a Node.js application, using a multi-stage build and a non-root user:

# Build stage
FROM node:lts-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
 
# Runtime stage
FROM node:lts-alpine
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

The build stage resolves dependencies, the runtime stage starts from a clean base and copies across only the installed modules plus your application code, and USER node stops the container from running as root. All three are habits worth forming early.

Building and running containers

Build an image from the Dockerfile and run a container, mapping a host port to a container port so you can reach it.

docker build -t my-app .
docker run -p 3000:3000 my-app

The first command builds an image tagged my-app from the Dockerfile in the current directory. The second runs a container from that image and maps port 3000 in the container to port 3000 on your host. Add -d to run it in the background, and use docker ps, docker logs and docker stop to inspect and stop it.

Using Docker Compose

Compose defines multi-container applications in a single compose.yaml file, so a web server, an API and a database start together with one command. It is integrated into the Docker CLI as docker compose and ships as the docker-compose-plugin on Linux and inside Docker Desktop.

Note the version numbering, because it confuses people. Compose v1 was the Python docker-compose script and is retired. Compose v2 was the Go rewrite invoked as docker compose. Compose v5, released in 2025, is functionally identical to v2 and adds an official Go SDK for embedding Compose in your own tooling. The command you type has not changed.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 5
 
volumes:
  pgdata:

Manage the stack with docker compose up, docker compose down and docker compose logs. Be careful with docker compose down -v, because the -v flag removes named volumes and therefore your database contents.

Two details trip people up regularly. Much of the deploy block is Swarm-only and is quietly ignored by docker compose up, including placement, update_config, rollback_config, endpoint_mode and mode: global. The exceptions are replicas, resources and restart_policy, which Compose does honour, and docker compose up --scale web=3 overrides the replica count at runtime. The second trap is container_name: set it and the service cannot scale at all, because two containers cannot share a name.

Using Docker Hub

Docker Hub is Docker’s official registry for discovering, storing and sharing images. It hosts Docker Official Images and Verified Publisher content alongside millions of community images, and gives a free account one private repository, with unlimited private repositories on paid plans. Pull a public image such as nginx or postgres for local use, and tag and push your own images to a personal or organisational repository with the standard CLI.

One practical detail that catches out CI pipelines: Docker Hub applies pull rate limits. Unauthenticated pulls are capped per IP address, authenticated Personal accounts get a higher allowance, and paid plans are unlimited. If your builds pull images anonymously from a shared network or a cloud CI runner, you will eventually hit the limit. Authenticate your pipeline, or mirror the images you depend on into your own registry. The current limits are published in Docker’s documentation.

Keeping data with volumes

Everything written inside a container is lost when that container is removed. To keep data you attach a volume, which is storage managed by Docker that lives outside the container lifecycle.

# Named volume, managed by Docker
docker run -e POSTGRES_PASSWORD=example -v pgdata:/var/lib/postgresql/data postgres:17
 
# Bind mount, a host directory mapped into the container
docker run -v $(pwd)/src:/app/src my-app

Named volumes are the right default for databases and application state. Bind mounts are useful in development because edits on your host appear immediately inside the container. One caveat worth knowing: a bind mount hides whatever already existed at that path inside the image, which is a common cause of “my files disappeared” confusion.

Potential risks and downsides

Docker offers real benefits, but it is worth understanding its limitations before committing to it.

Learning curve and complexity

Docker has a meaningful learning curve, particularly around networking, storage and image layering. Running a single container is easy. Running a production estate is not, and most teams reach a point where they need an orchestrator such as Kubernetes, which adds a second and much steeper learning curve on top.

Persistent data storage challenges

By design, all data inside a container disappears when the container is removed unless it was written elsewhere first. Volumes and bind mounts solve this, but backup, migration and performance of container storage remain more involved than with a traditional server. Many teams deliberately keep their primary database outside Docker in production for exactly this reason.

Limited GUI support

Docker was designed for server applications that do not need a graphical interface. Running GUI applications in containers is possible with X11 forwarding or a VNC server, but the setup is awkward and rarely worth it outside specific use cases such as browser testing.

Security and the container attack surface

Containers isolate processes, but they share the host kernel, so a kernel vulnerability has a wider blast radius than it would with virtual machines. The more common problem is simpler than that: containers built on outdated base images, running as root, with secrets baked into image layers.

The practical mitigations are well established. Pin and regularly update base images, run as a non-root user, scan images in the pipeline, keep secrets out of the image and inject them at runtime, and consider rootless mode, which runs the daemon and containers without root privileges on the host. Docker Scout reports vulnerabilities per image layer, and Docker Hardened Images offer minimal, continuously patched base images with signed provenance for teams that have to prove their supply chain.

What Docker costs

Docker Engine on Linux is free and open source. What is licensed is Docker Desktop and the Docker Hub and Docker platform services around it.

Docker Desktop remains free for personal use, education, open source projects and organisations with fewer than 250 employees and less than 10 million US dollars in annual revenue. Larger organisations, and government entities regardless of size, need a paid subscription. Paid tiers are Pro, Team and Business, priced per user per month, and they add unlimited Docker Hub pulls, private repositories, centralised administration and single sign-on at the higher tiers. Docker publishes the current thresholds and prices in the Docker plans FAQ.

The cost that catches organisations out is not the licence. It is the effort of running a container platform: registries, image lifecycle, patching, orchestration and the people who understand it. Budget for that before assuming containers will reduce operational spend.

Docker vs virtual machines

Understanding the difference between containers and virtual machines clarifies when to use each. A virtual machine virtualises an entire computer down to the hardware layer and runs a full guest operating system. A container virtualises only the application layer and shares the host kernel. Containers are therefore lighter and faster to start, while virtual machines provide a stronger isolation boundary.

Aspect	Docker containers	Virtual machines
Architecture	Shares the host OS kernel	Each VM runs its own full OS
Resource usage	Lightweight, megabytes per image	Resource intensive, gigabytes per image
Boot time	Seconds	Tens of seconds to minutes
Isolation	Process level, shared kernel	Hardware level, separate kernel
Security	Shared kernel widens the blast radius	Stronger isolation boundary
Portability	Highly portable as OCI images	Less portable across hypervisors
Guest OS choice	Must match the host kernel family	Any supported operating system
Typical use	Microservices, CI/CD, cloud native apps	Multi-tenancy, legacy systems, strict isolation

In practice the two are complementary rather than competing. Most containers in production run inside virtual machines provided by a cloud, which gives you the isolation of a VM at the tenancy boundary and the density of containers inside it.

Docker vs Podman, containerd and Kubernetes

Docker is not the only way to run containers, and the alternatives are often misunderstood as competitors when they occupy different layers.

• Podman is a daemonless, rootless-by-default container engine created at Red Hat and now a CNCF Sandbox project, with a CLI that is largely compatible with Docker’s. It appeals to teams with strict security requirements and to Red Hat estates. It builds and runs the same OCI images.
• containerd is the low-level runtime that Docker Engine itself uses. Kubernetes talks to it directly. It is infrastructure rather than a developer tool, so you rarely use it by hand.
• Kubernetes is an orchestrator, not an alternative to Docker. It schedules and manages containers across a cluster of machines and it runs the same images Docker builds. Kubernetes removed its Docker-specific shim in version 1.24, which led to a lot of confusion, but the practical effect for developers was none: images built with Docker still run on Kubernetes.

For most teams the sensible answer is that you build with Docker locally and run on whatever your platform provides. Because the image format is standardised, that choice stays reversible.

When should you not use Docker?

Containers are the default for good reasons, but they are not free and they are not always the right answer.

• For a single small application on a single server that rarely changes, a container adds a layer of tooling without solving a problem you have.
• For desktop software with a graphical interface, the container model fights you rather than helping.
• For workloads that need a different operating system kernel from the host, such as Windows applications on Linux hosts, you need a virtual machine.
• For hard multi-tenant isolation between untrusted workloads, the shared kernel is a genuine risk and virtual machines or microVMs are the safer boundary.
• For stateful databases in production, many teams still run them on managed services or dedicated hosts, and reserve containers for the stateless tiers.

The useful test is whether you have an environment problem, a scaling problem or a delivery-speed problem. If you do, Docker earns its complexity. If you do not, it is overhead.

Future outlook and final thoughts

Docker changed how the industry thinks about application deployment, and containers are now the assumed unit of delivery rather than an option to evaluate. The interesting developments are no longer in the runtime, which is stable and standardised, but in what sits around it.

Two directions are worth watching. The first is supply chain security: signed provenance, software bills of materials and minimal hardened base images have moved from a compliance exercise to a default expectation, driven partly by regulation such as the EU Cyber Resilience Act. The second is AI. Containers have become the packaging format for models, inference servers and agent tooling, and Docker has followed that demand with Model Runner, the MCP Toolkit and isolated sandboxes for coding agents.

For organisations, the practical implication is that container skills now sit on the critical path for both software delivery and AI deployment. The learning curve is real, but the payoff is consistent environments, reproducible deployments and infrastructure choices that stay reversible.

Take the next step with DataNorth AI

Containerisation is rarely the hard part of a project. Deciding what belongs in a container, how images are built and patched, where state lives and how deployments are governed is where the effort actually goes, and it is where most teams would benefit from a second opinion.

At DataNorth AI we work with organisations on exactly that: designing containerised architectures for AI and software workloads, setting up build and deployment pipelines that produce the same artefact every time, moving existing applications into containers without breaking them, and putting image security and vulnerability scanning in place before it becomes an audit finding. For most organisations this is a practical part of a wider digital transformation rather than a project on its own.

If you are weighing up containerisation, or already using Docker and want a review of how it is set up, get in touch and we will talk through your situation.

Frequently asked questions (FAQ) about Docker