Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Short answer: a Docker image is a read-only package and template; a Docker container is a runnable instance created from that image with its own runtime settings and writable layer. You build or download an image, then create and start one or more containers from it. Editing files in a container does not edit the image. Removing the container deletes its private writable layer unless the data was stored in a separately mounted volume or bind mount.
Docker’s own definitions are concise: “An image is a read-only template with instructions for creating a Docker container,” while “A container is a runnable instance of an image.” Keeping those roles separate makes commands, storage behavior and troubleshooting much easier to understand.
Image and container: the distinction in one view
| Aspect | Docker image | Docker container |
|---|---|---|
| Role | Read-only template or package used to create containers | Runnable instance of an image plus runtime configuration |
| How it is made | Built from a Dockerfile and build context, or downloaded from a registry | Created from an image with options such as command, network and mounts |
| Filesystem | Layered filesystem whose image layers are treated as immutable | Image layers plus a container-specific writable layer and any mounted storage |
| Multiplicity | One image can be the basis for many containers | Each container has an independent lifecycle and writable layer |
| What removal does | Removing a container does not change its source image | Removing a container removes its writable layer; separately mounted data can remain |
| Typical commands | docker build, docker pull, docker image ls |
docker create, docker run, docker ps, docker stop, docker rm |
Think of an image as a packaged filesystem plus startup defaults, closer to a prepared software package than to a bare text recipe. A container is the process environment produced when Docker applies those defaults and your run-time choices, adds a private writable layer and starts a process inside the resulting isolated environment.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How Docker turns an image into a running container
1. Write a Dockerfile and choose a build context
A Dockerfile contains instructions for assembling the application filesystem and its defaults. The build context is the set of files made available to the build; in the common example below, the current directory is the context:
#1 Best Overall
docker build -t my-app .The -t my-app option assigns a convenient tag. The command reads the Dockerfile and context, creates image layers and stores the resulting image locally. A registry can later distribute that image to other machines.
2. Obtain an image when you do not build one
You can download an existing image with docker pull, or refer to an image in another command. If the requested image reference is not available locally, Docker pulls it from the configured registry before creating the container. An image reference such as nginx:alpine identifies an image; it is not a container name or ID.
3. Create a container without starting it
docker create prepares a container and records its configuration, but leaves it in the created state:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsdocker create --name my-app my-imageThe name my-app identifies this particular container. You can start it later:
docker start my-appThis two-step form is useful when creation and startup need to be controlled separately, or when you want to inspect a container before its process runs.
4. Create and start in one operation
docker run combines creation and startup. It must include an image reference:
docker run --name my-app my-imageDocker creates a new container from my-image, applies the command, network, storage and other options supplied on the command line, and starts the container’s process. If the image is absent locally, Docker pulls it from the configured registry first. The command does not “turn the image into” a permanently changed image; it creates a separate runtime object.
Recommended Free Tools
5. Observe and control the lifecycle
Use these commands to see where a container is in its lifecycle:
docker pslists running containers.docker ps -alists running, stopped and created containers.docker stop my-appstops the container process but leaves the container object in place.docker start my-appstarts an existing stopped container again.docker rm my-appremoves the container and its writable layer.
Stopping and removing are different actions. A stopped container still exists and can be restarted; a removed container no longer has that lifecycle state or its private writable layer.
What is inside an image?
An image packages the files, binaries, libraries and configuration required to run an application. It also contains instructions and defaults used when a container is created, such as the program that should start if no replacement command is supplied.
Images are assembled in layers. Each filesystem-changing instruction in a build can contribute a layer, and layers can be reused by multiple images or containers. The image’s layers are read-only from the container’s point of view. If a process later writes to a path that came from an image layer, Docker records that change in the container’s writable layer rather than modifying the original image.
Because the image remains unchanged, the same image can reliably serve as the starting point for development, testing and production containers. To create a new version of the application package, change the Dockerfile or build context and run another build; do not rely on edits made inside a running container as an image-update method.
What makes a container different?
A container combines three things:
- The selected image: the read-only files and defaults.
- Runtime configuration: choices made at creation or startup, including the command, network settings and mounts.
- Container state: a private writable layer and the process state created while it runs.
Docker describes containers as isolated processes. They are not full virtual machines: the isolation model and available resources depend on the host, Docker configuration and options used to start the container. A container can be stopped and started again, but it is still a separate object from the image that supplied its initial filesystem.
Layers, writable data and persistence
Image layers are shared read-only foundations
When several containers use the same image, they can reuse the image’s underlying layers. This avoids treating every container as a completely separate copy of the package. The containers do not, however, share each other’s private writable layer.
Every container gets its own writable layer
Docker adds a container-specific writable layer above the image layers. A file created or changed in one container is recorded there and is not automatically visible as a change in another container created from the same image. Two containers can therefore start from identical image content while developing different runtime state.
Removing a container removes its writable layer
The writable layer is tied to the container’s lifecycle. When you remove the container, Docker removes that layer as well. Data written only there should be considered disposable. Stopping a container does not remove the layer, so a stopped container can retain those changes until it is removed.
Use a volume or bind mount for data that must survive
For databases, uploads, generated files or any other data that must outlive a container, attach storage explicitly. Docker recommends volumes for persistence, sharing and write-intensive workloads. A bind mount maps a host path into the container; a volume is managed separately by Docker. In either case, the mounted location is distinct from the container’s writable layer and can remain after the container is removed, subject to the mount’s own lifecycle and cleanup commands.
A practical rule is: treat the writable layer as temporary application state, and treat a volume or bind mount as intentional persistent storage. Make the mount part of the container-creation command or your deployment configuration so a replacement container receives the same data.
Can multiple containers come from one image?
Yes. One image can be the basis for any number of containers. Each invocation of docker run creates a new container unless you explicitly start an existing one by name or ID. Give containers distinct names when you need to address them individually:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutedocker run --name app-one my-image
docker run --name app-two my-imageBoth containers use the same image layers, but each has its own lifecycle, runtime configuration and writable layer. They can also receive different commands, networks or mounts. Sharing an image does not make their private filesystem writes appear in one another.
Image references, container names and IDs
Many command errors come from mixing up identifiers:
- Image reference: selects the package to use, for example
my-imageornginx:alpine. - Container name: identifies a created runtime object, such as
my-app. - Container ID: Docker’s identifier for that runtime object; commands that target a particular container accept its ID or name.
docker run IMAGE expects an image reference. After the container exists, docker stop, docker start and docker rm operate on the container name or ID instead.
docker create versus docker run
| Command | Creates a container? | Starts its process? | When to use it |
|---|---|---|---|
docker create --name my-app my-image |
Yes | No; state is created |
When you need a separate preparation step or want to start later |
docker run --name my-app my-image |
Yes | Yes | For the normal create-and-start workflow |
docker start my-app |
No; it uses an existing container | Yes | To restart a stopped or previously created container |
If you run docker run repeatedly with the same image, Docker normally creates additional containers. If you intend to reuse the original container and its writable layer, use docker start with that container’s name or ID.
A complete example workflow
The following sequence shows the conceptual path without hiding the separate objects:
- Build:
docker build -t my-app .creates themy-appimage from the Dockerfile and current-directory context. - Create:
docker create --name my-app-dev my-appcreates a configured container but does not start it. - Inspect the inventory:
docker image lsshows local images, whiledocker ps -ashows the created container. - Start:
docker start my-app-devruns the configured process. - Stop:
docker stop my-app-devstops that process while retaining the container. - Restart or discard: use
docker start my-app-devto reuse it, ordocker rm my-app-devto remove it and its writable layer.
If the application writes important data, add the volume or bind-mount option when creating the container rather than hoping files in the writable layer will survive removal.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common misconceptions and the accurate replacement
“A container is just an image.”
An image is the reusable package; a container is the configured runtime instance. The container adds a writable layer and process state, so two containers from one image can behave differently.
“Changing a file in a container changes the image.”
It does not. The write goes to the container’s writable layer or to a mount. Build a new image when you need a durable package change.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →“Stopping deletes the container.”
Stopping only stops the process. The container remains listed by docker ps -a and can be started again. Removal is a separate operation.
Best Value
“All container files persist.”
Only data kept in a surviving mount is designed to outlive container removal. Data in the writable layer disappears with the container.
“A container is a lightweight virtual machine.”
Docker containers are isolated processes, not complete virtual machines. Their isolation and resource boundaries depend on configuration and the host environment.
“Image size plus container size equals disk usage.”
Shared layers can be reused, and image listings may represent cumulative image and parent-layer sizes. Do not add displayed image and container figures as though every byte were unique.
Storage-driver details and the current implementation caveat
Layer terminology remains useful for understanding image and container behavior, but the underlying storage implementation is version-sensitive. Docker’s classic storage-driver documentation focuses on traditional drivers and notes that fresh Docker Engine 29.0 or newer installations use the containerd image store by default. Consequently, examples describing a particular classic driver may not match the implementation on a newly installed 29.0+ engine. The practical rules still hold: image content is treated as read-only, containers receive runtime state, and persistent application data belongs in an explicitly managed mount.
Troubleshooting by symptom
A command says the image cannot be found
Check that you supplied an image reference, not a container name. If the reference is correct and the image is not local, Docker will attempt to pull it from the configured registry. For a locally built package, verify the tag used in docker build -t ... and use that exact reference.
You cannot restart a container after deleting it
Removal is permanent for that container object and its writable layer. Create a new container from the image. If the application data was stored in a volume or bind mount, attach the same storage to the replacement.
Files disappeared after recreating a container
That is expected when the files were written only to the old container’s writable layer. Recreate the container with the required volume or bind mount, then write application data to the mounted path.
Two containers do not see each other’s file edits
Each container has its own writable layer. Use an explicitly shared volume or another suitable shared-storage design when containers must exchange files; do not assume that using the same image shares runtime changes.
A stopped container still appears in listings
This is normal. Use docker ps for running containers and docker ps -a for all containers, including stopped ones. Remove the object with docker rm only when you no longer need its writable state.
A practical decision checklist
- Do you need a reusable application package? Build or pull an image.
- Do you need to execute that package with a command and runtime settings? Create a container.
- Do you need a second isolated copy? Create another container from the same image.
- Do you need data after container removal? Use a volume or bind mount.
- Do you need to reuse the same container state? Stop and start the existing container instead of removing it.
- Do you need a durable software change? Update the Dockerfile or build context and build a new image.
- Are you diagnosing a storage implementation? Check the Docker Engine version and whether the containerd image store is in use before applying classic storage-driver assumptions.
The key mental model is therefore a sequence, not a synonym: Dockerfile plus build context → image → create and configure → container → start process. Keeping the package, runtime object, writable state and persistent mounts distinct explains what every major Docker command does and tells you exactly which data will survive the next stop, restart or removal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
