Docker Inventory

Docker Inventory shows Docker runtime data reported by endpoint agents.

The endpoint Docker tab shows the latest Docker inventory for one endpoint. Fleet-wide Docker image and container pages use the same collected data for cross-endpoint investigation.

The tab is available on agent endpoints when Docker inventory exists or when Docker inventory can be collected for that endpoint.

Docker support is currently Linux-only in the agent.

Collection

Use the Collect Docker inventory job step, or the endpoint inventory recollect action, to refresh the tab.

The agent reads Docker through its configured Docker connection:

• default Unix socket: /var/run/docker.sock
• optional TLS Docker endpoint configured in the agent config

For TLS Docker access, configure:

• docker.host
• docker.client_certificate_path
• docker.client_key_path
• optionally docker.ca_bundle_path

Do not configure docker.socket_path together with docker.host.

Overview

The overview section shows runtime details such as:

• runtime
• daemon version
• API version
• access method
• operating system
• architecture
• kernel version
• Docker root directory
• container, image, volume, and network counts

It also lists detected Docker Compose projects.

Compose projects are detected from Docker container labels, including:

• com.docker.compose.project
• com.docker.compose.project.working_dir
• com.docker.compose.project.config_files
• com.docker.compose.service

If a compose project has no running or existing containers, it may not be detected by inventory.

Containers

The containers section lists discovered containers with:

• container name
• container ID
• image and image ID
• state
• status

Users with Docker instruction permission can run direct container actions from the endpoint tab:

• start
• stop
• restart
• tail logs

These actions are issued as endpoint instructions and require the endpoint to be connected.

The log tail action reads the latest container log lines through Docker and shows them in the UI. It is intended for quick inspection, not as long-term log retention.

Images

The images section lists:

• image tags
• image ID
• image digests
• image size

Docker image update checks are handled separately from the endpoint tab. The endpoint tab shows what the endpoint reported in its latest Docker inventory.

Ordyn checks discovered image references against configured container registries and reports two different update kinds:

• version update available: a newer matching stable tag was found
• tag digest changed: the current tag points to a different remote digest

The registry tracking behavior can be customized in Container Registries.

Use Docker image tracking rules when a repository has multiple maintained branches, such as 3.6.x and 3.7.x, or when a repository should only be monitored for digest drift.

Volumes

The volumes section is read-only.

It shows:

• volume name
• driver
• mountpoint
• scope

Ordyn does not expose destructive volume operations from the endpoint UI.

Networks

The networks section is read-only.

It shows:

• network name and ID
• driver
• scope
• whether the network is marked internal by Docker
• whether the network is attachable

Docker Compose Jobs

Docker Compose management is available through job steps only.

The job steps expect the compose file to already exist on the endpoint. Ordyn does not upload, edit, or generate compose files for these steps.

Available compose actions:

• Docker Compose up
• Docker Compose down
• Docker Compose stop
• Docker Compose restart
• Docker Compose update
• Docker Compose exec

Docker Compose update runs pull and then up -d --remove-orphans. Enable Force recreate containers on Compose up/update job steps when unchanged containers should be recreated explicitly.

Docker Compose exec runs a non-interactive shell command inside a service from the compose project. It uses the configured compose file path list and service name, then runs the command through sh -lc inside the container.

Compose jobs accept multiple compose files. Ordyn passes each path as its own -f argument, preserving Docker Compose override-file behavior.

Discovered Compose projects are available to job loops as endpoint.docker.compose_projects. Each project contains:

Field	Type	Description
project	string or null	Compose project name reported by the running containers.
working_dir	string or null	Project working directory reported by Compose.
config_files	string list	Unique Compose file paths reported for the project, including override files. Projects without a reported config file are omitted.
services	string list	Unique Compose service names reported by the project containers.
compose_image_parse	object	Whether uninterpolated service images were parsed. status is parsed or unavailable; reason identifies why parsing was unavailable.
service_images	object list	Uninterpolated Compose image references and parsed tag metadata for each service.
image_updates	object list	Newer tracked tags available for images used by this project.

Each image_updates item contains:

Field	Type	Description
compose_service	string	Compose service using the image.
image_identifier	string	Docker image identifier reported by the endpoint.
registry_host	string	Registry containing the image.
repository_name	string	Repository path inside the registry.
current_reference	string	Normalized image reference currently used by the service.
current_tag	string	Tag currently used by the service.
newest_available_tag	string	Newer tag selected by the applicable tracking policy.
newest_available_reference	string	Complete registry, repository, and newer tag reference.
checked_at	string or null	Time of the successful cached registry check.
tracking_strategy	string or null	Tracking strategy used to select the newer tag.
compose_tag	object or null	Parsed Compose tag metadata for the service image.

The compose_tag object contains:

Field	Type	Description
raw	string	Tag text from the uninterpolated Compose image, such as ${API_TAG:-latest} or 1.4.0.
variable_name	string or null	Environment variable that can safely receive a complete replacement tag.
operator	string or null	Compose interpolation operator, such as :- or :?.
is_variable	boolean	Whether the tag contains Compose variable interpolation.
is_updateable	boolean	Whether the complete tag can safely be updated through one environment variable.

Whole-tag variables such as $API_TAG, ${API_TAG}, ${API_TAG:-latest}, and ${API_TAG:?required} are updateable. Literal tags and expressions containing prefixes, suffixes, alternatives, multiple variables, nested variables, or digest pins are not updateable.

Use a for_each step over endpoint.docker.compose_projects, followed by a nested loop over loop.vars.compose_project.image_updates. When compose_tag.is_updateable is true, use a Write key/value file value step with operation Update existing, key compose_tag.variable_name, and value newest_available_tag. Run the Compose action as a later, separate step.

The job must provide the target dotenv path explicitly. Compose values can come from the shell, the default .env, or a custom environment file, so the parsed variable name does not identify which file a workflow should edit. An empty image_updates list means that the existing configured tags remain unchanged; a Compose update can still pull newer image content published behind those tags.

The context reads the latest Docker inventory stored for the endpoint. Inventory reports are processed asynchronously, so a loop immediately after a collection step can still read the preceding stored project snapshot. Registry checks are also cached and asynchronous. Collecting Docker inventory during a job does not wait for a new registry check, and pending, unsuccessful, unused, or unchanged images do not appear in image_updates.

See Docker Compose update for a complete job-task example.