Docker Registry Inspector

Paste docker inspect output, image manifests, or registry configuration to analyze metadata, audit layers, inspect ports and environment variables, and detect security misconfigurations.

docker inspect Image Manifests Layer Analysis Port Inspection ENV Audit Registry Config Free · No Login

What This Tool Analyzes

docker inspect Output

Parses JSON from docker inspect IMAGE or docker inspect CONTAINER to extract image ID, architecture, OS, created date, layers, ports, and config.

Image Metadata

Surfaces key image properties: base OS, architecture, total layers, creation date, digest, author, and registry source from inspect JSON.

Environment Variables

Lists all ENV variables defined in the image. Flags variables with names suggesting hardcoded secrets like passwords, tokens, and API keys.

Exposed Ports

Extracts all EXPOSE directives from the image config. Flags sensitive ports like SSH (22), database ports (3306, 5432), and cache ports (6379).

Layer Inspection

Parses RootFS layers and build history. Shows layer count, layer digests, and identifies which instructions created each layer.

Registry Configuration

Analyzes registry config files for insecure registry settings, missing TLS, open mirrors, and authentication configuration issues.

How to Get Docker Inspect Output

  1. Inspect an image: docker inspect ubuntu:22.04
  2. Inspect a running container: docker inspect CONTAINER_ID
  3. Get image history: docker history IMAGE_NAME --no-trunc
  4. Get image manifest: docker manifest inspect IMAGE:TAG
  5. Copy the output and paste it into this tool for analysis.

Click Load Sample Output to see the inspector in action with a pre-built docker inspect JSON example.

Why Inspect Docker Registry Metadata?

Understanding Docker Registry Components

Image Digest vs Image Tag

A tag like node:20 is a mutable pointer that can be updated to reference a new image. A digest like sha256:abc123... is an immutable content hash. For production deployments, always reference images by digest to ensure you're running exactly what you tested.

Image Layers and RootFS

Each Docker image consists of read-only layers stacked on top of each other. Every RUN, COPY, and ADD instruction in a Dockerfile creates a new layer. Fewer layers mean smaller images and faster pulls. The RootFS.Layers field in docker inspect output lists the SHA256 digest of each layer.

Registry Configuration

Docker registries are configured via /etc/docker/daemon.json (on Linux) or Docker Desktop settings. Key settings include insecure-registries (registries accessible over HTTP), registry-mirrors (pull-through caches), and log-driver. Misconfigurations here can expose images to interception or unauthorized access.

Frequently Asked Questions

What does "docker inspect registry" mean in practice?

When developers search for "docker inspect registry" they typically want to examine what images are stored in a registry, inspect image metadata before pulling, or audit registry configuration. This tool helps by parsing the output of docker inspect, docker manifest inspect, and registry API responses.

How do I find secrets accidentally embedded in a Docker image?

Secrets can be embedded via ENV instructions (visible in docker inspect), via COPY of config files with credentials, or in RUN command history (visible in docker history). This tool scans ENV variables and history output for common secret patterns. For deeper scanning, use tools like truffleHog or Trivy secrets scanning on the built image.

What is an insecure Docker registry?

An insecure registry is one accessed over HTTP instead of HTTPS, or one using a self-signed certificate without proper trust configuration. Docker blocks pulls from insecure registries by default. To allow them (only on internal networks), add the registry to insecure-registries in /etc/docker/daemon.json. Never use insecure registries over public networks.

How many layers should a Docker image have?

Docker images are limited to 127 layers. Best practice is to keep layer count low (under 15-20) by chaining RUN commands with &&, using multi-stage builds, and cleaning up package caches in the same layer they were created. More layers increase image size and pull time.