Conceptly
← All Concepts
πŸ–ΌοΈ

Docker Image

CoreAn immutable bundle of files and defaults for running a container

A Docker image is the immutable package that contains the filesystem and defaults needed to start a container. A running container is an execution instance built from that image plus a small writable layer.

β–ΆArchitecture Diagram

πŸ” Structure

Dashed line animations indicate the flow direction of data or requests

Why do you need it?

If deployment still means copying files and reinstalling dependencies on each server, the result drifts over time. One server has an extra package, another missed an environment variable, and rollback becomes guesswork. Teams need a single unit that freezes the execution starting point.

Why did this approach emerge?

Older deployment workflows separated package files, install scripts, and operations notes. In the container world, it proved more effective to freeze the full runtime environment as one artifact. Once CI/CD became the norm, images and tags naturally turned into the standard release unit.

How does it work inside?

An image stacks a base layer, dependency layers, application files, and runtime metadata. Each layer is read-only, so rebuilding creates new results instead of mutating old ones. Shared layers also make storage and transfer more efficient across many images.

Boundaries & Distinctions

A Docker image and a container registry both sit in the delivery path, but they solve different problems. The image is the executable package. The registry is the place where that package is stored and distributed.

When should you use it?

Most production workflows now deploy image tags rather than copying source code to servers. When teams tie image tags to commits or release versions, they gain far better traceability for what is actually running and how to roll it back.

Application deploymentVersion pinningRollbackTeam sharing