Docker inspect returns low-level information about Docker-managed objects. It helps explain which image a container references, what mounts it uses, and what the daemon reports about its state. It is a read operation, but its output can still be sensitive and its interpretation can still lead to mistaken operational decisions.
Use it as a targeted evidence tool. Choose the daemon context and object type, extract only the fields needed, and compare observed state with the intended deployment configuration. A large JSON dump is not automatically a useful incident report.
Confirm the daemon and object identity
A Docker client can talk to different daemon contexts. Before inspecting an operational workload, confirm that the client is connected to the intended environment. A valid container name on a development daemon does not answer a production question.
The general inspect command can match different object types by name or ID. A container and a volume can have the same name. Use the --type option when the workflow expects one specific kind of object.
Prefer an exact recorded ID where identity matters, especially in a script that spans several operations. A familiar container name can be reused after replacement. Keep observation time and daemon context with saved evidence so later readers know which instance was inspected.
Docker inspect supports narrow field selection
For an authorized container, a targeted query can look like this:
docker inspect --type=container \
--format='{{.Id}} {{.Image}} {{.State.Status}}' \
app-container
docker inspect --type=container \
--format='{{json .Mounts}}' \
app-containerThe name is illustrative. The first command selects identity, image reference information, and state. The second uses Docker’s JSON formatting helper for the mount structure rather than relying on a Go-style display dump.
Keep the format under application control. Select fields according to the investigation, and avoid retrieving the entire configuration when only a mount source or state flag is required. Less collection reduces accidental disclosure and makes comparisons easier.
Configuration and current state answer different questions
A container’s configuration describes how it was created. Its state describes what the daemon currently reports about its execution. An intended restart policy, a stopped process, and a healthy application are not the same fact.
Environment configuration is not a complete view of runtime secrets. Values can also come from files, mounted secret material, external services, or process behavior. Conversely, environment fields may contain credentials that should never be copied into a public troubleshooting message.
Compare observed settings against the authoritative deployment specification. Do not reconstruct a permanent deployment solely from an inspection dump; it may include incidental addresses, ephemeral state, and changes made outside the reviewed workflow.
Interpret mounts as a storage boundary
Mount information helps distinguish named volumes, bind mounts, and other storage arrangements. Record the destination and source relevant to the application data path. A visible directory inside the container may be backed by external storage rather than the writable container layer.
This matters for backups and export operations. The existence of a mount does not prove that its contents are included in a container filesystem archive. It also does not prove application consistency at the time data was copied.
Review writable versus read-only settings, but do not assume a read-only mount makes the entire application incapable of modifying data elsewhere. Other mounts and container paths may remain writable.
Port mappings are not a connectivity test
Inspect can show container-side ports and host binding details. A service may have several bindings, different host addresses, or no published binding for a listed container port.
Do not parse only the first binding and present it as the complete exposure model. Preserve the relevant address, port, protocol, and network context. A mapping bound to loopback has different external reachability from one bound broadly, but firewall and routing behavior still need verification.
Container IP addresses can change after replacement and may be meaningful only inside the Docker network. Avoid turning an observed internal address into a permanent client configuration when service discovery is the intended interface.
Use an authorized connection test from the relevant source network to verify actual reachability. A configuration record can explain intended wiring without proving that a process is listening or that an end-to-end request succeeds.
Size fields have a limited scope
The --size option adds container filesystem size information, including the total root filesystem size and the size of created or changed files relative to the image. It works for containers, including stopped ones.
These fields are not a complete storage bill for the application. Mounted data, logging arrangements, and shared image storage need separate accounting. A small writable-layer figure does not mean a database workload consumes little disk space.
Avoid summing root filesystem values across containers as though all bytes were independently allocated. Shared image layers and the daemon’s storage implementation affect actual host usage. Use the appropriate storage tools and a clear accounting question.
Redact evidence before sharing
Full inspect output can contain environment values, labels, command arguments, host paths, and network information. Treat it as operational data, not harmless metadata. Store it only where the investigation’s access rules permit.
Use an allowlist of fields for routine diagnostic collection. Redacting a few familiar key names from an unrestricted dump can miss a secret stored under an unexpected name or embedded in an argument.
For scripts, parse JSON with explicit expectations and handle missing fields deliberately. Do not execute strings from object names, labels, or command fields. A contributor-controlled label can remain untrusted even when the daemon faithfully returns it.
Test comparisons against replacement and failure
Use fixtures for a running container, a stopped container, a replaced instance with the same name, multiple network bindings, and different mount types. Include missing optional fields and a command failure caused by the wrong context or insufficient access.
Capture exit status before parsing output. An empty report from a failed inspect operation should not be labeled “no mounts” or “no exposure.” Keep absence, permission failure, and transport failure distinct.
When investigating drift, compare selected stable configuration fields and exact identities. Do not flag every ephemeral timestamp or assigned address as an unauthorized deployment change.
Frequently asked questions
Does inspect change a container?
The command reads information. Later actions based on its output, such as restart or deletion, are separate operations that need their own authorization and review.
Can it prove an application is healthy?
It reports daemon state and configured health information where present. Verify the real application behavior and the health check’s scope separately.
Is the full JSON safe to send to support?
Not without review. Prefer a narrow field collection and redact sensitive values according to the support workflow’s access policy.
Practical takeaway
Inspect the correct object on the correct daemon, retrieve only necessary fields, and distinguish configuration from observed behavior. Preserve storage and network context while protecting sensitive data. Useful diagnostics explain a state without claiming more than the evidence shows.
Documentation and related reading
Check the official documentation for the exact behavior of your deployed version. For complementary implementation guidance, read the Docker export scope guide.
Continue with the Docker Guides for a broader practical reading path.
