What Is a Docker Container? Docker Containerization, Images and Commands Explained

A Docker container is a running instance of a Docker image. It is an isolated process on your machine that contains your application and everything the application needs to run: the runtime, libraries, system tools and configuration. Because containers share the host’s kernel instead of booting their own operating system, they are lightweight, start in seconds and run the same way on any machine that has Docker.

In this article I explain what a container is technically, what “containerization” actually means, how a container is different from an image, and I show you how to run, list, stop and remove containers with a real example. This is the written version of my video above, updated with current commands.

If you are completely new to Docker, I recommend reading What is Docker first. It explains the container concept and why it was needed in the first place.

What is a Docker container?

A Docker container is a standardized, isolated unit that runs one application with all of its dependencies. You create it from a Docker image with a single command like docker run, and from that moment it is a normal process on the host that can only see its own files, network and processes.

Think of it like this: instead of installing PostgreSQL, Redis or your own Node.js app directly on your laptop or on a server, you start each of them in its own container. Each container brings its own versions of everything it needs, so they don’t conflict with each other or with whatever is installed on the host.

A container has three important properties:

• Packaged: the application, its dependencies and its configuration travel together as one unit
• Isolated: the container has its own file system, network interfaces and process list, separate from the host and from other containers
• Portable: the same image runs the same way on a developer laptop, in a CI/CD pipeline and on a production server

What is Docker containerization?

Containerization is the process of packaging an application with all of its dependencies into a container image, so it can run in an isolated container on any host. Docker containerization simply means doing this with Docker: you describe the application’s environment in a Dockerfile, build an image from it, and run that image as a container.

Before containerization, you deployed an application by installing it, its runtime and all its libraries directly on a server’s operating system, often following a long installation guide. Every server had to be configured correctly, and two applications on the same server could need conflicting versions of the same library. Containerization moves all of that configuration into the image, so the server only needs Docker.

Technically, containerization is a form of operating system level virtualization. A container is not a small virtual machine. It is a process that the Linux kernel isolates using two features:

• Namespaces give the container its own view of the system: its own process IDs, network, mount points and hostname
• Control groups (cgroups) limit how much CPU, memory and other resources the container can use

Docker made these kernel features easy to use with simple commands and a standard image format. Today container images follow the open OCI (Open Container Initiative) standard, so an image you build with Docker can also run with other container tools, for example on Kubernetes.

Here is what containerization gives you in practice:

Without containerization	With Docker containerization
Install runtime and libraries on every server by hand	Everything the app needs is inside the image
Version conflicts between apps on the same machine	Each container has its own isolated dependencies
“Works on my machine” but fails on the server	The same image runs the same way everywhere
Long setup guides for new developers	One docker run command per service
Hard to run two versions of the same software	Run as many versions side by side as you need

The full workflow looks like this: you write a Dockerfile, build an image, push it to a registry, and anyone (or any server) can pull it and run it as a container.

What is a Docker image?

A Docker image is the package: a read-only template that contains the application, its dependencies and the instructions for starting it. It is the artifact that you build once, store in a registry like Docker Hub, and move around between environments.

An image doesn’t do anything on its own. It is just a file lying around in a registry or on your disk. Only when you run it does it become a container.

What is the difference between a Docker image and a container?

An image is the package, and a container is that package running. If it’s not running, it’s an image, just an artifact that’s lying around. When you start it on a machine, the application inside starts and you have a container. You can start many containers from the same image, just like you can start many processes from the same program.

	Docker image	Docker container
What it is	A read-only package (template)	A running instance of an image
State	Static, doesn’t change	Has a state: created, running, stopped
Writable	No, made of read-only layers	Yes, adds a thin writable layer on top of the image
Where it lives	In a registry (Docker Hub, private registry) and on disk	On the host where it was started
How you create it	docker build from a Dockerfile, or docker pull	docker run (or docker create) from an image
How you list it	docker images	docker ps (running) and docker ps -a (all)
How many	One image per version of your app	As many containers from one image as you need

A good analogy for developers: the image is like a class, and a container is like an object created from that class.

What is a Docker container made of? Image layers

A container is built from an image, and an image is made up of layers stacked on top of each other. At the bottom there is usually a small Linux base image, like Alpine or a slim Debian. On top of it come the layers with the application runtime and the application itself, and then configuration.

Base images should be small, which is why many images offer an Alpine variant. Small base images keep containers small, and that is one of the big advantages of containers over virtual machines.

When you start a container, Docker adds a thin writable layer on top of the read-only image layers. Anything the application writes, like log files or temporary data, goes into that writable layer. When you remove the container, that layer is gone. That’s why you use volumes for data that must survive, like database files.

Layers also make Docker efficient. Each layer is downloaded and stored separately, so if two images share the same base layers, Docker only downloads and stores them once. You’ll see that in the demo below.

How do you run a Docker container? A practical example

Let me show you how a container looks in practice, using PostgreSQL as an example.

1. Find the image on Docker Hub

Docker Hub is the public registry for Docker images. If you search for “postgres”, you find the official PostgreSQL image, maintained and verified by Docker.

On the image page you see all the available versions, called tags. In the video I used an older Postgres version; the commands are exactly the same with current versions.

Because it’s a public image, you don’t need to log in or configure anything to download it.

2. Pull and run the image

You can download an image with docker pull, but docker run does both: it pulls the image if it’s not on your machine yet, and then starts a container from it. If you don’t specify a tag, Docker uses latest. I always recommend specifying a version:

docker run -d --name my-postgres -e POSTGRES_PASSWORD=mysecretpassword postgres:17

What the options mean:

• -d runs the container in the background (detached)
• --name my-postgres gives the container a name, so you don’t have to use its ID
• -e POSTGRES_PASSWORD=... sets an environment variable; the official Postgres image needs a password to start
• postgres:17 is the image name and tag

The first thing Docker prints is “Unable to find image locally”, so it pulls the image from Docker Hub:

Each line with a hash is one image layer being downloaded separately. If you later download a newer Postgres version, most layers are the same and won’t be downloaded again. Only the layers that changed are fetched, so the second download is much faster.

As soon as the download finishes, Docker starts the container, and the Postgres start script runs. Without -d you would see the logs directly; with -d you can view them with docker logs my-postgres. At the end you see “database system is ready to accept connections”.

3. List running containers

With docker ps you see all running containers:

docker ps

Notice the “IMAGE” column: every container is started from an image. That’s the image vs container distinction in action. PostgreSQL is now running on your machine, and you didn’t install anything except Docker.

How do you stop, start and remove a Docker container?

A container has a simple lifecycle: it is created, it runs, it can be stopped and started again, and finally it is removed. Stopping a container keeps it (and its writable layer) on your disk; removing it deletes it. The image stays until you remove it separately.

Here are the basic commands you need every day:

Command	What it does
docker pull postgres:17	Download an image from a registry
docker images	List images on your machine (same as docker image ls)
docker run -d --name my-postgres ... postgres:17	Create and start a new container from an image
docker ps	List running containers
docker ps -a	List all containers, including stopped ones
docker logs my-postgres	Show a container’s logs
docker exec -it my-postgres psql -U postgres	Run a command inside a running container
docker stop my-postgres	Stop a running container
docker start my-postgres	Start a stopped container again
docker rm my-postgres	Remove a stopped container
docker rmi postgres:17	Remove an image that no containers use

One thing that confuses many beginners: docker run always creates a new container. If you want to continue with a container you stopped, use docker start, not docker run.

Can you run multiple containers of the same application?

Yes. You can run as many containers as you want, from the same image or from different versions of the same application, and they don’t conflict because each one is isolated.

For example, if you need a second Postgres version for another project, you just run it with a different name:

docker run -d --name old-postgres -e POSTGRES_PASSWORD=mysecretpassword postgres:16

Docker pulls only the layers it doesn’t have yet. When you run docker ps again, you see both Postgres containers running side by side:

If you want to connect to them from your laptop, you publish each container’s port to a different host port, for example -p 5432:5432 for one and -p 5433:5432 for the other. Inside, both listen on 5432; on your machine they are reachable on two different ports.

Try doing that with two native installations of the same database. That is exactly why containers make development environments so much easier.

Docker container vs virtual machine: what’s the difference?

A container shares the host’s kernel and only packages the application layer, while a virtual machine runs a complete operating system with its own kernel. That makes containers much smaller (megabytes instead of gigabytes) and much faster to start (seconds instead of minutes), while VMs give stronger isolation and can run any operating system.

In practice you often use both: in the cloud, your containers usually run on virtual machines. I explain this in detail in my article Docker vs Virtual Machine.

Frequently asked questions

What is a Docker container in simple terms?

A Docker container is a box that contains your application and everything it needs to run, isolated from the rest of the machine. You start it from an image with one command, and it runs the same way on any computer with Docker. Technically, it is an isolated process that shares the host’s operating system kernel.

What is Docker containerization?

Docker containerization is packaging an application with its dependencies into a Docker image and running it as an isolated container. Instead of configuring each server for each application, you configure the application once in a Dockerfile, and every environment only needs Docker installed. It is a form of operating system level virtualization based on Linux namespaces and cgroups.

What is a Docker image?

A Docker image is a read-only package that contains an application, its dependencies, configuration and the command to start it. It is made of layers and is stored in a registry such as Docker Hub. When you run an image, Docker creates a container from it.

What is the difference between a Docker image and a container?

An image is the static package, and a container is a running instance of that image. The image is read-only and can be shared through a registry, while a container has a state (running or stopped) and a writable layer for its runtime data. You can start many containers from one image.

Is a Docker container a virtual machine?

No. A virtual machine runs a full guest operating system with its own kernel, while a container is an isolated process that uses the host’s kernel. That’s why containers are much lighter and start much faster than VMs.

What happens to data when a Docker container is removed?

Data written inside the container’s writable layer is deleted together with the container. Stopping a container keeps the data, but removing it does not. For data that must survive, like database files, you use Docker volumes, which live outside the container’s lifecycle.

Where to go from here

To understand why containers were needed in the first place, read What is Docker and What problem does Docker solve. For a deeper look at containers vs VMs, read Docker vs Virtual Machine, and when you start building your own images, follow my Docker best practices. You can find all my Docker articles and guides on the Docker topic page.