A Docker image is a bundled, read-only file that contains everything required to run an application—system libraries, code, runtime, tools, and settings. It acts as a portable snapshot of an environment, allowing developers to ship and execute applications consistently across platforms.
When a container is launched from a Docker image, it adds a writable layer on top of this image. This architecture enables stateless application deployment, where images can be versioned, shared, and reused without the complexities of traditional configuration and installation routines.
Why It’s Important to Know Where Images Are Stored
Understanding where Docker images reside can help you:
- Free up disk space by removing unused images.
- Manage local caches and storage quotas.
- Set up backup or migration strategies.
- Understand performance implications on systems with limited storage.
System administrators, DevOps engineers, and security professionals often need to audit or analyze stored images, especially in multi-user environments or when orchestrating containers across servers.
Local vs Remote Image Storage Explained
Docker images are stored in two main forms:
- Locally, on the host running the Docker daemon.
- Remotely, in registries like Docker Hub, Google Container Registry, or private repositories.
When you run docker pull, Docker fetches the image from a remote registry and stores it on your local system. Conversely, when you create a new image using docker build, it exists only locally until pushed to a remote registry using docker push.
Understanding both locations helps manage storage efficiently, particularly in CI/CD pipelines, deployment scripts, or when scaling container workloads.
The Default Local Storage Path
By default, Docker stores images and other data at:
/var/lib/docker/
This directory contains everything Docker uses and creates—including images, containers, volumes, and networks. Inside this folder, several subdirectories are organized by purpose and storage driver.
Depending on the storage driver, image files may be distributed across different directories. For instance:
- aufs driver stores layers in /var/lib/docker/aufs/
- overlay2 driver stores data in /var/lib/docker/overlay2/
- btrfs uses /var/lib/docker/btrfs/
- devicemapper stores its data under /var/lib/docker/devicemapper/
Among these, overlay2 has become the default driver in most modern Linux distributions due to its performance and stability.
Storage Drivers: The Real Decision Makers
Docker’s behavior for storing images is governed by its storage driver—a subsystem that defines how the image and container layers are maintained on disk. Each driver has its own internal structure and strategy.
Overlay2 Driver
As the most widely adopted storage driver, overlay2 uses a union mount filesystem to stack image layers. Each layer corresponds to a directory within /var/lib/docker/overlay2/. These directories contain the actual filesystem changes introduced in each image layer.
Additionally, metadata files describe relationships among layers. Docker uses this information to create the merged, read-only view that containers can use.
AUFS Driver
Though older and less popular today, aufs was the original default storage driver on Ubuntu. Like overlay2, it uses a layered filesystem, but its directory structure differs slightly.
Its usage has declined due to limited upstream support and complexities during kernel upgrades.
Devicemapper Driver
This driver stores data at the block level rather than the file level. It’s more complex and harder to inspect manually. Used mainly in older CentOS or RHEL systems, devicemapper creates loopback devices that simulate virtual block storage.
Btrfs Driver
Btrfs provides advanced features like snapshotting and deduplication, making it an interesting choice for sophisticated storage environments. However, it requires Btrfs support at the filesystem level, which limits its general use.
Breaking Down the Image Layer Concept
Docker images consist of multiple layers stacked together. Each instruction in a Dockerfile (RUN, COPY, ADD, etc.) creates a new layer.
These layers are:
- Immutable: They cannot be changed once created.
- Cached: Docker can reuse unchanged layers to optimize performance.
- Shared: Multiple images or containers may reuse the same layers, saving disk space.
Each layer is stored separately on disk under a unique identifier, usually a long hexadecimal hash. Docker uses a manifest file to link these layers together into a single image.
When an image is updated, only the new or changed layers are saved, making Docker efficient both in terms of time and storage.
Docker Image Metadata
In addition to the filesystem layers, Docker stores metadata that includes:
- Image configuration files (e.g., environment variables, commands, labels)
- Image manifest and history
- Digests and hashes for layer integrity
This metadata is typically found within /var/lib/docker/image/ under a driver-specific folder. For instance:
/var/lib/docker/image/overlay2/imagedb/content/sha256/
These files ensure consistency and allow Docker to manage versions, detect corruption, and optimize caching.
How to View Stored Images
To list all locally stored images, you can use:
docker images
This command provides information such as repository name, tag, image ID, and size. Internally, each of these entries corresponds to a series of layer directories and metadata files under Docker’s root storage directory.
Advanced tools and commands like:
- docker inspect
- docker image ls –digests
- docker system df
- docker image prune
can help analyze, audit, and clean up Docker images without needing to explore the filesystem manually.
What Happens When You Pull an Image?
When you run docker pull ubuntu, Docker performs several steps:
- Connects to the registry (e.g., Docker Hub).
- Downloads the image manifest.
- Checks which layers are already present locally.
- Downloads only the missing layers.
- Stores each layer under its unique directory.
- Registers the image with its metadata for future reference.
This process ensures efficiency and avoids redundant downloads.
Layer Reuse Across Images
One of Docker’s major strengths lies in how it manages shared layers. For instance, if two images are based on the same base image (like python:3.11), their base layers are stored only once.
This mechanism:
- Reduces disk usage
- Speeds up builds
- Improves performance when spinning up containers
Layer sharing works both for locally built and pulled images, so it’s especially useful in environments where multiple microservices rely on common dependencies.
Image Storage in Windows and macOS
Docker Desktop on Windows and macOS runs Docker within a lightweight virtual machine. Hence, the image storage path is not directly accessible from the host OS.
Internally, Docker Desktop uses a Linux VM and stores image files inside that VM. The VM image itself resides in locations such as:
- ~/Library/Containers/com.docker.docker/ on macOS
- %USERPROFILE%\AppData\Local\Docker\ on Windows
Users don’t typically access or modify these files directly, but tools like Docker Desktop’s GUI or CLI commands provide visibility and control over the stored images.
Customizing Docker’s Storage Location
Administrators may want to move Docker’s root directory (/var/lib/docker/) to a different disk, especially on systems with limited space. This can be achieved by:
- Editing the Docker daemon configuration file (/etc/docker/daemon.json)
- Using the –data-root command-line option
- Restarting the Docker service to apply the new root path
By relocating the data directory, you can store Docker images on faster SSDs or high-capacity HDDs, depending on performance needs.
Storage Cleanup and Maintenance
Over time, unused images can consume significant space. To manage storage efficiently:
- Use docker image prune to remove dangling images
- Use docker system prune to clean up all unused data
- Use docker builder prune to target build cache layers
Docker also allows tagging and untagging images to manage their lifecycle. Untagged images can become dangling layers, which might accumulate and bloat storage unless regularly pruned.
Security Implications of Stored Images
Stored Docker images may contain sensitive information, especially if built improperly. Examples include:
- Hardcoded credentials
- SSH keys
- Debug tools
- Environment secrets
Thus, it’s critical to monitor and inspect locally stored images. Removing obsolete images, scanning for vulnerabilities, and limiting access to Docker’s storage directories are recommended practices.
What Are Docker Registries?
A Docker registry is a storage and distribution system for named Docker images. It allows users to store images remotely, making them accessible from anywhere and shareable across teams or environments. While local storage is sufficient for development and testing, production environments and collaborative projects rely on registries to streamline deployment and scalability.
Registries can be public or private. Public registries allow universal access, whereas private ones restrict access and often support authentication, logging, and security policies.
The most commonly used registry is Docker Hub, which serves as the default registry for Docker Engine. However, many organizations prefer self-hosted or cloud-based registries tailored to their needs.
How Docker Images Are Stored Remotely
When an image is pushed to a registry, it is split into layers—just like local images. Each layer is identified by a digest (SHA256 hash), ensuring consistency and reducing redundancy.
The remote storage process includes:
- Compressing image layers.
- Calculating digests for each layer.
- Uploading only the layers that don’t already exist in the registry.
- Updating the image manifest to track all associated layers and metadata.
This layered approach enables registries to optimize storage and network usage, particularly when handling multiple images that share common bases or dependencies.
Docker Hub: The Default Public Registry
Docker Hub is the central repository used by Docker CLI when no specific registry is mentioned. It hosts millions of official, community-contributed, and custom images.
When you run docker pull nginx, Docker Hub is queried by default unless another registry is configured. Docker Hub categorizes images as follows:
- Official Images: Maintained by Docker and vetted for security.
- Verified Publisher Images: From trusted vendors and partners.
- Community Images: User-contributed, often tailored to specific use cases.
Each repository on Docker Hub can host multiple image tags. For example, python:3.11, python:3.10-slim, and python:latest all belong to the same repository but represent different image builds.
Other Public and Cloud-Based Registries
Besides Docker Hub, several other registries offer scalable and feature-rich Docker image storage:
Google Container Registry (GCR) and Artifact Registry
Google’s solution for storing container images, these registries integrate well with Google Cloud services. Images are stored in geographically distributed locations to ensure high availability and speed.
Users push images using a specific path like:
gcr.io/project-id/image-name
Amazon Elastic Container Registry (ECR)
Amazon ECR is a managed AWS service that integrates tightly with ECS, EKS, and CodeBuild. It supports fine-grained IAM access controls and uses encrypted storage to enhance security.
Images are pushed and pulled using:
aws_account_id.dkr.ecr.region.amazonaws.com/image-name
Azure Container Registry (ACR)
Azure ACR provides similar capabilities within the Microsoft Azure ecosystem. It allows developers to push, pull, and manage Docker images securely using Azure Active Directory.
GitHub Container Registry (GHCR)
Part of GitHub Packages, GHCR allows storing Docker images alongside your codebase. It supports access permissions via GitHub organizations and teams.
Quay.io, JFrog Artifactory, and Harbor
These registries offer flexible, enterprise-grade solutions. Quay.io is popular for its automated scanning features, while JFrog and Harbor support multiple artifact types and hybrid cloud deployment.
Private Docker Registries
Organizations often prefer hosting their own registry to gain full control over image storage, authentication, access policies, and retention.
Docker provides a simple solution called the Docker Registry—an open-source registry server. It can be deployed using the official Docker image and supports features like:
- SSL encryption
- Basic authentication
- Custom storage backends (local, Amazon S3, Azure Blob)
To use a private registry, you tag and push images using the registry address:
bash
CopyEdit
docker tag myapp localhost:5000/myapp
docker push localhost:5000/myapp
The registry stores the image layers and metadata in a specified directory or backend service, depending on the configuration.
The Anatomy of a Remote Image
A Docker image stored in a registry is composed of:
- Blobs: The actual compressed layer files
- Manifests: Descriptive files mapping layers to their digests and configuration
- Tags: Human-readable references pointing to a specific manifest
The registry saves blobs in a content-addressable storage, meaning each file is retrievable using its digest. This structure ensures deduplication, meaning layers reused by multiple images are stored only once.
How Pulling Images Works
When a user pulls an image:
- The Docker Engine queries the registry for the manifest.
- It checks which layers are already available locally.
- Missing layers are downloaded from the registry.
- All downloaded layers are stored in the Docker data root (/var/lib/docker/).
- The engine reconstructs the image using local and downloaded layers.
This intelligent caching mechanism drastically reduces bandwidth usage and speeds up repeated pulls.
Image Tagging and Versioning in Registries
Docker images in registries are identified by tags. A tag typically represents a specific version or configuration. For example:
- node:18
- node:18-slim
- node:18-alpine
Tags simplify deployment scripts and CI/CD pipelines. However, it’s important to remember that tags are mutable—they can point to different images over time unless pinned by digest.
To ensure immutability, Docker also supports pulling images by digest:
docker pull nginx@sha256:abcdef…
This guarantees the exact image is used, regardless of tag changes.
Authentication and Authorization
Accessing private registries requires authentication. Docker supports:
- Basic authentication with username and password
- OAuth tokens
- IAM roles (in cloud environments)
- Encrypted certificates
Authorization policies control who can read, write, or delete specific images. Most registries implement role-based access control (RBAC) to manage permissions across users, teams, or organizations.
Image Retention and Cleanup Policies
Large-scale environments can accumulate vast numbers of image versions. Registries support automated policies to prune unused or old images. Common practices include:
- Keeping the last n image versions
- Deleting images untagged for over x days
- Removing images not pulled for a certain period
These policies help manage storage costs, especially in cloud registries where storage usage is billed.
Security in Image Registries
Security is a core concern for remote image storage. Vulnerabilities can be introduced via outdated packages, misconfigured dependencies, or embedded secrets.
Modern registries support:
- Vulnerability scanning: Tools scan for known CVEs in image layers.
- Signed images: Image signing ensures the image comes from a trusted source.
- Audit logs: Registries track image uploads, downloads, and deletions.
- Content trust: Enabling Docker Content Trust enforces image integrity verification.
These features protect against supply chain attacks and unauthorized usage.
Registry Storage Backends
Registries don’t necessarily store images as simple files on disk. They can use:
- Local filesystems
- Object storage (e.g., S3, Azure Blob, Google Cloud Storage)
- Distributed file systems
The choice depends on scalability needs. Object storage is ideal for high-availability, geo-redundant setups, while local filesystems suffice for small, self-hosted registries.
Layer Reuse Across Remote Images
Just like local environments, registries benefit from shared image layers. If two images share a base (like alpine or debian), only new or changed layers are uploaded.
This optimization saves storage space and network bandwidth, and accelerates CI/CD pipelines by avoiding redundant uploads.
Pushing Images: What Happens Internally
When a user pushes an image to a remote registry:
- Docker calculates SHA256 digests for each image layer.
- It checks which layers already exist in the registry.
- Only new layers are uploaded.
- The image manifest and configuration file are uploaded last.
- The image is assigned or updated under a specified tag.
This process is resilient and can resume partial uploads in case of network interruption.
Container Registries in CI/CD Workflows
Registries play a pivotal role in automation pipelines. Common practices include:
- Storing build artifacts: CI servers build Docker images and push them to a registry.
- Image promotion: Tagging and moving images from development to staging to production.
- Rollback: Keeping historical image versions allows reverting to known good states.
Build tools like Jenkins, GitLab CI, GitHub Actions, and CircleCI integrate natively with Docker registries to automate this process end-to-end.
Best Practices for Remote Image Storage
To ensure an efficient and secure remote storage environment:
- Tag images semantically (v1.0.0, latest, stable)
- Use lightweight base images (alpine, distroless)
- Implement image scanning in CI/CD
- Regularly delete stale or dangling images
- Avoid storing sensitive data in image layers
- Enforce image signing and content trust
Challenges in Managing Remote Images
Despite their benefits, registries come with challenges:
- Storage costs grow rapidly without pruning
- Misconfigured authentication can expose sensitive images
- Poor tagging strategies lead to version confusion
- Lack of visibility into image usage can result in bloat
Proactive monitoring and governance are required to maintain registry hygiene.
Monitoring and Observability
Advanced registries support dashboards and APIs for visibility into:
- Storage consumption
- Image pull/download trends
- Failed upload attempts
- Tag lifecycles and history
These insights guide capacity planning and security auditing.
Why Production-Grade Storage Strategy Matters
In production environments, Docker image storage is not simply about placing files on disk or pushing to a registry. It involves strategic decisions that affect performance, scalability, security, and maintainability. As businesses grow and containers multiply, managing the storage, lifecycle, and distribution of Docker images becomes mission-critical.
Organizations operating on cloud-native principles or orchestrating containers through platforms like Kubernetes must prioritize how images are stored, pulled, tagged, replicated, and pruned. These decisions influence build pipelines, deployment speed, network efficiency, and even cost structures in cloud-based environments.
Image Lifecycle Management
A robust image lifecycle management policy helps teams avoid clutter, reduce risk, and improve deployment efficiency. The typical lifecycle of a Docker image includes:
- Creation or build
- Tagging for environments (dev, staging, production)
- Push to a registry
- Usage in deployments
- Retirement or deletion
This cycle is not static—it evolves with continuous delivery workflows and updates. Production strategies must therefore include automated tagging, expiration, and archival rules.
Key recommendations include:
- Enforce consistent naming conventions (e.g., semver, commit hash, build ID).
- Retain only the most recent builds for CI/CD.
- Tag stable versions to differentiate them from experimental ones.
- Archive important releases for audit and rollback purposes.
Optimizing Storage Efficiency on the Host
On individual servers or Docker hosts, storage management should focus on reducing bloat while maintaining performance. Even though Docker uses layering and caching, image duplication and dangling artifacts can accumulate over time.
Practical measures to maintain cleanliness include:
- Scheduled pruning using tools like docker image prune and docker system prune.
- Limiting the number of retained images per service.
- Mounting Docker’s data root on high-performance storage.
- Offloading build caches using remote cache support in modern builders.
When Docker hosts run out of disk space, container creation can fail, potentially causing application downtime. It’s critical to monitor disk usage and plan storage capacity accordingly.
Using Image Scanning and Policies
Security in production requires proactive scanning of all Docker images. Many organizations unknowingly ship vulnerabilities embedded in base images or third-party layers.
Security best practices include:
- Running image vulnerability scans during CI/CD.
- Blocking deployments of images with known high-severity CVEs.
- Using registries that support automatic scanning (e.g., Harbor, Quay, GitHub Container Registry).
- Regularly updating and rebuilding images to pick up upstream patches.
Image scanning tools such as Trivy, Clair, or Aqua Microscanner can be integrated into build pipelines. These tools identify vulnerable libraries, outdated packages, and misconfigurations before images are pushed to production.
Layer Caching and Build Optimization
One of the most significant performance benefits of Docker comes from its build cache. When image layers don’t change, Docker can reuse them during builds, speeding up image creation and reducing disk usage.
However, improper Dockerfile design can negate caching benefits. Some recommendations include:
- Place the most frequently changing instructions (like COPY .) lower in the Dockerfile.
- Group static instructions (like apt-get install) early to cache more layers.
- Use .dockerignore files to exclude unnecessary files from build context.
- Split multi-purpose images into base and application-specific layers.
For larger projects, enabling remote layer caching with services like BuildKit or GitHub Actions caching significantly reduces CI build times.
Using Multistage Builds
Multistage builds help produce leaner, more secure production images. By separating build and runtime stages, only necessary binaries and files are included in the final image.
For example, you might compile your application in one stage and copy only the executable into the final image. This results in smaller images, faster transfers, and reduced attack surfaces.
Multistage builds are particularly useful for compiled languages (Go, Rust, Java) and are now considered a best practice in enterprise image design.
Deployment Considerations and Pull Behavior
In high-scale environments like Kubernetes, hundreds of containers may pull the same image simultaneously. Poor image distribution strategies can lead to network bottlenecks, registry throttling, or increased start-up latency.
To address this, consider the following:
- Use pull-through caches to mirror frequently used images closer to deployments.
- Preload critical images on nodes using docker pull during cluster setup.
- Use private registries inside the same network to eliminate outbound requests.
- Consider registry replication across regions for distributed applications.
Large-scale systems often implement image pinning, ensuring all workloads run the exact same image version, avoiding surprises due to tag drift.
Registry Mirroring and Proxying
Registry mirroring helps optimize pull performance and minimize external bandwidth usage. By setting up a local mirror of Docker Hub or any other registry, organizations can:
- Improve download speeds
- Reduce dependency on internet connectivity
- Enforce version control policies
This is commonly achieved with the Docker Registry’s proxy mode or tools like Harbor, which allow mirroring selected images. Kubernetes clusters in air-gapped environments often rely heavily on mirrored registries.
Image Replication and Redundancy
In cloud-native architectures, registries should be replicated across data centers or regions to improve availability and fault tolerance. This is especially important when latency affects deployment or autoscaling times.
Strategies include:
- Multi-region registry replication (e.g., in AWS ECR or GCR)
- Geo-replication in Harbor or Artifactory
- Backup and restore mechanisms for private registries
By replicating registries, DevOps teams can ensure that regional outages or network partitions do not stall deployments.
Monitoring Docker Image Storage
Monitoring is essential to detect image bloat, storage exhaustion, or unauthorized access. Some observability practices include:
- Tracking image pulls and push frequency.
- Measuring registry size and growth over time.
- Alerting on low disk space in Docker hosts.
- Logging access and download events for audit trails.
Registry UIs (e.g., Harbor or JFrog) provide dashboards, while cloud platforms integrate with monitoring suites like Prometheus, Grafana, or CloudWatch to track image usage and performance.
Immutable Infrastructure and Image IDs
For reproducible and auditable deployments, use immutable image references. While tags are convenient, they are mutable and can lead to unpredictable results.
Instead, production systems should:
- Use full image digests (image@sha256:…) to guarantee identical deployments.
- Document image hashes in deployment manifests.
- Store release artifacts in versioned buckets or repositories for traceability.
Tools like Kubernetes and Terraform support digest-based references, ensuring that application rollouts always use known-good images.
Cleaning Up with Automation
Manual image cleanup is impractical at scale. Automation tools can identify and remove unused, outdated, or orphaned images.
Some common strategies include:
- Scheduled pruning jobs (using cron or CI pipelines).
- Custom scripts to delete images older than a threshold.
- Retention policies within registries.
- CI/CD steps to clean local cache after builds.
Automated cleanup prevents disk saturation and improves overall performance without impacting ongoing deployments.
Separation of Build and Runtime Images
To enhance security and maintain clarity, separate images for building and running applications. Build images may contain compilers, debug tools, or credentials—all of which are unnecessary and risky in runtime.
By isolating concerns, organizations can:
- Reduce attack surfaces
- Meet compliance requirements
- Streamline runtime environments
- Ensure portability and consistency
Tools like Docker Multistage Build make this separation trivial and highly maintainable.
Integrating Image Governance Policies
Governance involves enforcing standards across how images are built, stored, tagged, and deployed. It includes:
- Naming conventions for all repositories and tags.
- Approval workflows before publishing to production registries.
- Automated scanning pipelines before allowing image pushes.
- Version locking and immutability enforcement.
Central image governance ensures consistency across teams and reduces the likelihood of mistakes that could lead to vulnerabilities or system failures.
Role of Content Delivery Networks (CDNs)
Modern registries integrate with CDNs to accelerate image distribution. CDNs cache image layers across edge locations, reducing latency for globally distributed deployments.
This approach is particularly effective for:
- SaaS platforms with users in multiple regions
- High-traffic services scaling rapidly
- Reducing egress costs in cloud environments
CDN-backed registries also improve reliability by handling traffic spikes more gracefully than single-point registry deployments.
Best Practices Checklist for Production
To summarize, here are key best practices when managing Docker image storage in production:
- Always tag images semantically and immutably.
- Use digest-based references for critical deployments.
- Regularly scan images for vulnerabilities.
- Clean up unused images with automation.
- Use multistage builds for minimal runtime images.
- Monitor disk usage and image access patterns.
- Replicate and mirror registries for high availability.
- Enforce access controls and audit logs.
- Separate build and runtime environments.
- Integrate registry usage into CI/CD workflows.
These guidelines form a solid foundation for reliable, secure, and efficient Docker image management in professional environments.
Future Trends in Image Storage and Distribution
As containerization matures, the landscape of image storage continues to evolve. Anticipated trends include:
- OCI image enhancements: The Open Container Initiative is driving a more unified image specification, improving portability across platforms.
- Image streaming: Technologies like lazy-pull or Nydus file system allow containers to start before fully downloading the image.
- Zero-trust registries: Future registries may require verification before access or execute runtime validation.
- Immutable infrastructure: Images will be more tightly coupled with deployment tools, enforcing reproducibility from code to runtime.
By staying ahead of these developments, organizations can ensure their container infrastructure remains agile, scalable, and secure.
Conclusion
Docker has fundamentally reshaped the way modern applications are developed, packaged, and deployed. At the heart of this revolution lies the Docker image—a portable, layered, and version-controlled snapshot of an application environment. Understanding where these images are stored, both locally and remotely, is essential for ensuring efficient, secure, and scalable containerized workflows.
Locally, Docker relies on a structured directory system governed by storage drivers, organizing images and layers under /var/lib/docker/ or an alternative data root. Each storage driver brings its own nuances, impacting how data is written, cached, and reused. These mechanisms are critical for optimizing host performance and conserving disk resources, especially in environments with frequent builds or ephemeral containers.
Remotely, Docker images are stored in registries—whether public, cloud-managed, or privately hosted. These registries act as centralized distribution platforms, supporting versioning, access control, security scanning, and scalability. Efficient registry use ensures consistency across deployments, accelerates delivery pipelines, and enforces governance policies through tagging strategies and access management.
In production environments, storage strategy becomes more than a technical detail; it is a pillar of reliability, performance, and compliance. Real-world practices such as layer caching, multistage builds, registry mirroring, image scanning, and digest-based deployment reinforce operational excellence. Integrating these strategies into CI/CD workflows and infrastructure automation enables teams to manage images as first-class assets within the software delivery lifecycle.
As containers become the default unit of software deployment, mastering the principles of Docker image storage empowers organizations to build faster, deploy safer, and scale smarter. With a combination of foundational knowledge, strategic architecture, and automation, Docker image storage evolves from a behind-the-scenes detail into a cornerstone of modern DevOps practice.