Where Are Docker Images Stored? File Locations Explained

Containers stop working. Disk space vanishes mysteriously. Your build pipeline breaks during deployment. These common Docker problems often trace back to a single question: where are Docker images stored and how does this storage system work?

Docker’s image storage isn’t just a technical detail—it’s fundamental to successfully running containerized applications. The container filesystem works differently across operating systems, with unique storage paths for Linux, macOS, and Windows environments. Whether you’re managing Docker storage on a single development machine or orchestrating container image distribution across production clusters, understanding the Docker daemon data directory structure is essential.

This guide explores exactly where Docker stores your images, from the image layers storage in /var/lib/docker/overlay2 on Linux to Docker Desktop’s VM-based storage on macOS and Windows. You’ll learn how Docker’s storage drivers impact image location, discover effective methods for managing Docker disk space, and master techniques for optimizing your Docker storage configuration.

By the end, you’ll understand:

• Default storage locations across all major operating systems
• How storage drivers affect where and how images are stored
• Practical commands for monitoring and managing image storage
• Advanced strategies for production environments
• Troubleshooting techniques for common storage issues

Where Are Docker Images Stored?

Docker images are stored in several places, depending on your setup:

1. Local Docker Engine: When you pull or build images, they’re stored locally in the Docker daemon’s storage directory:
   • On Linux: /var/lib/docker/
   • On macOS: In a VM managed by Docker Desktop, accessed via the Docker Desktop app
   • On Windows: C:\ProgramData\Docker\windowsfilter (Windows containers) or in a VM (Linux containers)
2. Registry: Docker images are typically distributed through registries:
   • Docker Hub (public registry)
   • Private registries (Harbor, Nexus, AWS ECR, Google GCR, Azure ACR)
   • Self-hosted registries
3. Image Layers: Docker uses a layered filesystem where each image consists of multiple read-only layers, with containers adding a writable layer on top.

You can view locally stored images using:

docker images

Or get more detailed information:

docker system df -v

To see where exactly Docker stores data on your system:

docker info | grep "Docker Root Dir"

Is there a specific aspect of Docker image storage you’d like me to explain in more detail?

Default Storage Locations

Linux Storage Paths

Docker storage architecture organizes container images in a logical way. On Linux systems, Docker stores all its data in /var/lib/docker. This Docker daemon data directory handles everything related to your containers and images.

The /var/lib/docker directory contains several subdirectories:

• containers: Stores container-specific files
• image: Holds image metadata and references
• overlay2: Where image layers actually live
• volumes: Manages persistent data
• network: Contains network configuration

The most important folder for image storage is /var/lib/docker/overlay2. This is where the container filesystem layers reside. Each image consists of multiple content addressable storage layers stacked together.

When you run docker pull, image blobs download to this location. The overlay2 storage driver (the default on most systems) handles how these layers work together.

Image metadata lives in separate locations from the actual binary data. This Docker library location helps the container runtime storage system track what you have locally.

macOS Storage Locations

Docker Desktop for Mac works differently. It runs inside a lightweight VM since Docker needs Linux kernel features.

The Docker.raw file contains everything – all your images, containers, and volumes. This virtual disk image grows dynamically as you add more content.

Finding this file might surprise you. It’s typically located at:

~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

Accessing the VM storage from macOS requires special steps. The Docker storage configuration keeps this abstracted for most users.

Docker Desktop versions have changed paths over time. Newer versions might use different locations, so check documentation for your specific version.

Windows Storage Paths

Windows offers two Docker backend options: WSL2 and Hyper-V.

With the WSL2 backend (now the default), Docker images live inside the Linux subsystem. The exact path depends on your WSL2 distribution, but typically follows Linux conventions.

For legacy Hyper-V backends, Docker uses a dedicated VM. Container image files store in a virtual hard drive at:

C:\Users\[YourUsername]\AppData\Local\Docker\wsl\data\ext4.vhdx

Docker Desktop data location can be customized. File access between Windows and Docker environment happens through mapped drives.

Storage Drivers and Their Impact

Available Storage Drivers

Docker supports multiple storage drivers, each using different techniques for container image hosting:

1. Overlay2: The default and recommended storage driver offers the best balance of performance and compatibility. It uses the overlay filesystem to stack image layers.
2. AUFS: An older storage engine still used on some systems. It was the original Docker storage driver but has been largely replaced.
3. Btrfs: Leverages the Btrfs filesystem’s snapshot features. This storage backend works well when your host uses Btrfs natively.
4. ZFS: Similar to Btrfs, it uses ZFS filesystem capabilities for image layer caching and management.
5. Device Mapper: Uses direct device management. Popular in enterprise environments and Red Hat-based systems.

Your choice affects Docker image management significantly. Container image distribution also changes based on your selection.

How Storage Drivers Affect Image Location

Storage structure differences between drivers can be dramatic. Each driver organizes data differently:

• Overlay2 creates directories for each layer
• Device Mapper uses block devices
• ZFS and Btrfs use filesystem-specific features

Performance variations exist too. Overlay2 generally offers the best read/write speeds for most workloads. Device Mapper thin provisioning might show slower container startup times.

Compatibility considerations matter when choosing a driver. Some only work on specific Linux kernels or filesystems. Docker storage monitoring becomes essential when optimizing for your environment.

When should you choose specific drivers? Consider:

• Use Overlay2 for most standard installations
• Choose Btrfs or ZFS if your host already uses these filesystems
• Device Mapper works better in certain enterprise environments
• AUFS only when other options aren’t available

The image layer deduplication strategy differs between drivers. This affects how efficiently Docker storage handles duplicate content across images.

Managing Docker disk space requires understanding how your specific driver stores and references image data. Docker storage troubleshooting starts with knowing which driver you’re using and its unique characteristics.

Managing Docker Image Storage

Checking Docker Disk Usage

Docker’s content addressable storage system can consume significant disk space. Track usage with simple commands.

Run docker system df to get a quick overview of space used by images, containers, and volumes. This reveals your Docker storage architecture at a glance.

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              12                  8                   3.85GB              1.2GB (31%)
Containers          8                   5                   34.2MB              12.1MB (35%)
Local Volumes       3                   3                   328B                0B (0%)
Build Cache         0                   0                   0B                  0B

Find large images with docker images and sort by size. This shows which container image files consume the most space.

Need deeper analysis? Try docker system df -v for verbose output showing detailed space usage. Container image metadata reveals which layers are shared or unique.

Monitoring storage growth helps manage Docker storage limits before problems occur.

Cleaning Up Unused Images

Docker image cleanup is essential for managing disk space. Several image management commands help with this.

Remove specific images with docker rmi:

docker rmi nginx:1.19

For bulk cleanup, use docker image prune to remove dangling images (those not associated with containers). Add -a to remove all unused images:

docker image prune -a

System-wide cleanup with docker system prune removes multiple unused resources:

docker system prune --all --volumes

Implement automated cleanup strategies using cron jobs or CI/CD pipelines. Docker storage monitoring scripts can trigger cleanup when thresholds are reached.

Moving Docker’s Storage Location

Need more space? Configure daemon.json to relocate the Docker library location:

1. Edit or create /etc/docker/daemon.json:

   {
     "data-root": "/path/to/new/docker/data"
   }
   

2. Restart Docker daemon:

   sudo systemctl restart docker
   

Relocating to external drives solves space constraints. The migration process for existing images requires careful planning to avoid data loss.

After changing Docker storage configuration, verify the new path with:

docker info | grep "Docker Root Dir"

Docker image migration should show all your previous content in the new location.

Registry and Remote Storage

Docker Hub and Other Registries

Container image repositories like Docker Hub provide remote storage for images. These remote registries function as centralized Docker image hosting services.

When you run docker pull nginx, the Docker daemon contacts Docker Hub (the default registry), downloads the image layers, and stores them locally. The Docker pull command’s mechanics affect how images are cached locally.

Registry caching behavior can be optimized. Docker stores layer blobs efficiently, downloading only what’s missing locally thanks to the image manifest location checks.

Private registry configurations offer alternatives to Docker Hub:

• Amazon ECR
• Google Container Registry
• Azure Container Registry
• GitHub Container Registry
• Quay.io
• Harbor Registry

Each registry implements the Docker Registry API and OCI Format standards for container image distribution.

Container Image Distribution Models

Teams face tradeoffs between local and remote storage. Local storage offers speed but consumes disk space. Remote registries provide centralized management but require network bandwidth.

Many organizations adopt hybrid approaches. Common patterns include:

• Local caching registries
• Registry mirrors
• Multi-stage builds to reduce image size
• Optimizing Docker storage with smaller base images

Image distribution in CI/CD pipelines often involves pushing to a private registry after successful builds. Jenkins, GitHub Actions, and other tools support the Docker push command as part of automation.

Network vs. storage optimization depends on your priorities. In bandwidth-constrained environments, focus on layer deduplication and compression. For storage-constrained systems, aggressive image cleanup and retention policies work best.

Docker image versioning through tags helps manage which versions to keep or remove. Proper image tag strategies prevent accidental deletion of critical images while enabling Docker storage troubleshooting and optimization.

Docker Storage in Production Environments

Multi-Host Considerations

Production deployments rarely rely on single hosts. Docker storage architecture becomes more complex when scaling across multiple servers.

Shared storage solutions help maintain consistency across nodes. NFS volumes, cloud storage, or specialized container storage interfaces provide access to the same Docker image layers from multiple hosts. This reduces unnecessary duplication of container image files.

Image distribution strategies matter in multi-host environments. Options include:

• Pull-through cache registries
• Local registry mirrors
• Registry per cluster region
• Pre-pulling critical images

Storage redundancy prevents downtime from disk failures. Many teams implement RAID configurations for the Docker daemon data directory or use cloud-provider redundant storage.

Disaster recovery approaches should include Docker image backup strategies. Regularly push critical custom images to remote registries or implement filesystem-level backups of the Docker storage location.

Orchestration Platforms

Kubernetes handles image storage differently than standalone Docker. The container runtime interface connects Kubernetes to containerd or other container runtimes, which manage local image storage.

Each Kubernetes node maintains its own local cache of container images in paths similar to Docker’s. When pods schedule to nodes, kubelet ensures required images exist locally.

Swarm mode storage follows Docker’s standard patterns but adds distribution awareness. Images pull only when needed on specific nodes.

Image caching in node clusters requires thoughtful planning. Consider:

• Cache warming for critical images
• Image garbage collection policies
• Storage driver consistency across nodes
• Node disk capacity planning

Container image metadata stays synchronized through the orchestration platform’s control plane. This ensures consistent deployment regardless of which node runs your workload.

The Docker registry API enables orchestrators to efficiently manage image distribution. Kubernetes, for example, implements sophisticated image pull policies and secrets for registry authentication.

Troubleshooting Storage Issues

Common Storage Problems

Storage issues frequently cause Docker headaches. Four problems appear most often:

“No space left on device” errors occur when the filesystem hosting /var/lib/docker fills up. This stops all operations requiring disk writes, including creating new containers or downloading images.

Corrupted image layers happen from interrupted downloads, disk errors, or Docker daemon crashes. Symptoms include containers failing to start with cryptic errors about missing files.

Storage driver conflicts emerge after system updates or changing drivers without proper migration. Container image hosting depends on consistent storage drivers.

Permission issues prevent Docker from writing to storage locations. This especially affects custom Docker storage configuration or mounted volumes.

Each issue connects to how Docker storage drivers interact with your host system.

Diagnostic Techniques

Start Docker storage troubleshooting by checking logs:

journalctl -u docker.service

Look for errors related to storage drivers, permission denials, or space issues.

Verify image integrity with:

docker image inspect <image-id>

This shows complete image layer information, helping identify corrupted layers in the container image repository.

Analyze storage driver performance with:

docker info

Check the storage driver section for warnings or errors. Performance issues often relate to misconfigured or inappropriate storage drivers for your workload.

Docker storage monitoring should include:

• Regular disk usage checks
• I/O performance monitoring
• Image layer growth tracking
• Registry connection reliability

When severe corruption occurs, recovery options include:

1. Removing and re-pulling affected images
2. Rebuilding local images from Dockerfiles
3. Restoring from backups
4. In extreme cases, migrating to a new Docker storage backend

Docker image inspection tools help diagnose which specific layers cause problems. Container image security scanning might detect corrupted layers before they cause operational issues.

Docker storage limits apply to various components:

• Maximum layers per image (127)
• Maximum image size (platform dependent)
• Registry-specific push limits
• Docker Hub rate limits

Understanding these constraints helps troubleshoot unexpected failures in your Docker storage engine.

Best Practices for Docker Image Storage

Image Optimization Techniques

Docker image optimization directly impacts storage efficiency. Multi-stage builds dramatically reduce image size by separating build-time dependencies from runtime needs.

Here’s a simple example:

# Build stage
FROM node:14 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

This approach eliminates unnecessary build tools from the final image layer, significantly reducing Docker storage requirements.

Using smaller base images makes a massive difference. Alpine-based images often measure 5-10MB compared to hundreds of megabytes for full distributions. The container filesystem becomes much leaner, improving Docker image distribution speed.

Layer optimization strategies require understanding how the Docker storage driver handles changes:

1. Order Dockerfile commands from least to most frequently changed
2. Combine related commands in single RUN statements
3. Remove temporary files in the same layer they’re created
4. Use .dockerignore to prevent unnecessary files from entering the image

The overlay2 storage driver handles these optimizations particularly well, making image layer caching more efficient.

Image vulnerability scanning should be part of your workflow. Tools integrated with your registry can flag security issues while also helping identify bloated images.

Storage Planning and Maintenance

Capacity planning prevents Docker storage troubleshooting emergencies. Analyze current usage patterns and project growth:

# Get baseline measurements
docker system df -v > storage-baseline.txt

Monitor this weekly to understand growth trends in your container image repository.

Set up Docker storage monitoring with alerts before space becomes critical:

#!/bin/bash
USAGE=$(df /var/lib/docker | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $USAGE -gt 85 ]; then
  echo "Docker storage at $USAGE%" | mail -s "Docker Storage Alert" admin@example.com
fi

Implement retention policies for images using tags and automated cleanup:

# Keep only last 3 versions of each image
docker images | grep myapp | sort -V | head -n -3 | awk '{print $3}' | xargs docker rmi

Docker image versioning through appropriate tagging makes this maintenance simpler.

Backup strategies for critical images should include:

1. Regular pushes to multiple Docker Hub or private registry locations
2. Using docker save to export images to tar files
3. Version control for Dockerfiles and build contexts
4. Documentation of image dependencies and configurations

Container image security measures should cover the entire lifecycle from build to storage to deployment.

Image distribution in CI/CD pipelines should include automated storage cleanup to prevent accumulation of outdated images. This Docker storage best practice prevents uncontrolled growth of your local Docker library location.

When optimizing Docker storage configuration, balance these factors:

• Performance needs
• Storage redundancy requirements
• Image layer deduplication benefits
• Registry caching behavior

The Docker storage backend you choose significantly impacts how these optimizations work. Most environments benefit from the default overlay2 driver, but specialized workloads might need different options.

Regularly review Docker image hosting options as your environment grows. Moving from Docker Hub to self-hosted Docker images or enterprise registry solutions might make sense at certain scale points.

Remember that Docker storage architecture decisions have long-term implications. Well-planned container image storage makes scaling, maintenance, and disaster recovery much simpler.

FAQ on Where Are Docker Images Stored

Where exactly are Docker images stored on Linux?

Docker stores images in the /var/lib/docker directory on Linux systems. This Docker daemon data directory contains multiple subdirectories including overlay2 (or your specific storage driver name), where the actual image layers reside. Each layer in the container filesystem has its own directory with a unique hash identifier. The Docker storage architecture separates metadata from the binary data, with manifest files stored separately from the actual content. You can verify your storage location by running docker info | grep "Docker Root Dir".

How can I change where Docker stores images?

Modify the Docker storage configuration by editing the daemon.json file. Create or edit /etc/docker/daemon.json and add:

{
  "data-root": "/path/to/new/location"
}

After changing the Docker library location, restart the Docker daemon with systemctl restart docker or equivalent for your system. This relocates the entire Docker storage backend, including all container image files. Verify the change took effect with docker info. Some users move Docker to larger drives when managing Docker disk space becomes challenging.

Where are Docker images stored on Windows?

Windows Docker image storage depends on your configuration. With WSL2 backend (default in newer Docker Desktop versions), images store inside the Linux subsystem, typically in a .vhdx file at %USERPROFILE%\AppData\Local\Docker\wsl\data\ext4.vhdx.

For Hyper-V backend, Docker Desktop stores images in a VM’s virtual hard drive. The container image repository lives inside this VM, not directly on the Windows filesystem. Access Docker settings to change storage locations or manage Docker storage limits.

How do I find and delete unused Docker images?

Use these commands for Docker image management:

# List all images
docker images

# Check space usage
docker system df

# Remove specific image
docker rmi image_name:tag

# Remove dangling images
docker image prune

# Remove all unused images
docker image prune -a

# Complete cleanup
docker system prune --all --volumes

Implementing Docker image cleanup regularly prevents storage issues. Image layer caching means some layers may be shared between images, so the Docker storage engine only removes layers not referenced by any remaining images.

Do I need to worry about Docker Registry storage separately?

Yes. Docker Hub and private registries like GitHub Container Registry, Amazon ECR, or Google Container Registry have their own storage systems. When using docker pull, images download from these registries to local storage. The Docker registry API handles this transfer efficiently.

Self-hosted Docker images in private registries require their own storage planning. Registry caching behavior affects network usage, while image distribution systems need proper monitoring. Consider implementing image vulnerability scanning and Docker storage monitoring for both local and registry storage.

How do containers and images share storage using layers?

Docker’s content addressable storage uses a layered approach. The OCI Format defines how image layers stack to create a complete container filesystem. When multiple containers use the same base image, they share those common image layers, saving significant space.

Each layer contains only the differences from previous layers. The overlay2 storage driver (the default) efficiently manages these layers, creating thin, stackable filesystems. This image layer deduplication is key to Docker’s storage efficiency. Container image hosting takes advantage of this to minimize redundant storage.

Can I move Docker images between machines without a registry?

Yes, use docker save and docker load:

# Export image to file
docker save my_image:tag > my_image.tar

# Transfer file to other machine

# Import image from file
docker load < my_image.tar

This creates a portable archive containing all image layers. It’s useful for Docker image migration or container image sharing in air-gapped environments. Remember that Docker image versioning through tags helps track these images properly.

Why is my Docker storage location running out of space?

Common causes include:

1. Unused containers with volumes
2. Dangling and unused images
3. Build cache accumulation
4. Large image layers from inefficient Dockerfiles

Use docker system df -v for detailed Docker storage troubleshooting. The container runtime storage grows over time without maintenance. Implement regular cleanup with automated scripts and optimize Dockerfiles using multi-stage builds to reduce image size.

How do Kubernetes and Docker Swarm handle image storage?

Orchestration platforms add complexity to Docker storage architecture. Kubernetes stores images on each node, pulling from registries as needed. The container image distribution happens independently on each node.

Docker Swarm uses the standard Docker storage engine but coordinates image pulls across the swarm. Both require careful image management strategies, especially for container image caching and storage monitoring. The Docker storage backend configuration should be consistent across all nodes in your cluster.

What happens to my images if I reinstall Docker?

Reinstalling the Docker daemon typically doesn’t affect images if you don’t remove the Docker storage location. However, backup critical custom images by:

1. Pushing to Docker Hub or private registry
2. Using docker save to export important images
3. Documenting your image build process

If you delete /var/lib/docker (or equivalent on your OS), you’ll lose all local images and containers. The Docker storage engine creates new storage structures upon reinstallation, but won’t recover previous data without proper backups.

Conclusion

Understanding where are Docker images stored forms the foundation of effective container management. The Docker storage engine operates differently across platforms, but the principles remain consistent: layered filesystems, content-addressable storage, and driver-specific implementations. Whether you’re working with the container image repository in Linux’s /var/lib/docker, navigating Docker Desktop’s VM on macOS, or managing WSL2 storage on Windows, knowledge of the underlying architecture empowers you to make informed decisions.

Container image hosting extends beyond local storage to registry systems and orchestration platforms. Docker image versioning, storage driver selection, and image layer deduplication all play crucial roles in optimizing your container workflow. As containerization continues to evolve, managing Docker storage limits and implementing proper image cleanup strategies becomes increasingly important for both development and production environments.

Remember that Docker’s strength lies in its flexibility. You can customize the Docker library location, choose appropriate storage backends, and implement registry caching behavior that suits your specific needs. By applying the best practices outlined in this guide, you’ll maintain efficient container image distribution while avoiding common storage pitfalls.

If you liked this article about where are Docker images stored, you should check out this article about Kubernetes vs Docker.

There are also similar articles discussing what is Docker hub, what is a Docker container, what is a Docker image, and what is Docker compose.

And let’s not forget about articles on where are Docker volumes stored, how to use Docker, how to install Docker, and how to start Docker daemon.

• Author
• Recent Posts

Bogdan Sandu

Bogdan is a seasoned web designer and tech strategist, with a keen eye on emerging industry trends.

With over a decade in the tech field, Bogdan blends technical expertise with insights on business innovation in technology.

A regular contributor to TMS Outsource's blog, where you'll find sharp analyses on software development, tech business strategies, and global tech dynamics.

Latest posts by Bogdan Sandu (see all)

• Kotlin Regex: A Guide to Regular Expressions - April 22, 2025
• What Is the Kotlin Enum Class? Explained Clearly - April 22, 2025
• How To Work With Maps In Kotlin - April 21, 2025