Containers

View your Docker containers and stream their logs.

The Containers page lists the Docker containers reported by your connected agents. Click a row to open that container's own detail page.

Container list

The table shows one row per container with:

Name: the container name
State: the container's Docker state (running or exited get their own badge color; anything else, like paused or restarting, shows as a warning)
Uptime: time elapsed since the container was created, shown for stopped containers too, not just running ones

Container detail page

Clicking a container opens three tabs:

Overview: source (Docker or Kubernetes), when it was created, live CPU/memory usage, the image it's running (click it to open that image's detail page), published ports, volume mounts, network and disk I/O, and labels.
Logs: live tail and full historical search, both scoped to this one container. See Logs for what each mode offers.
Exec (Enterprise): see below.

Terminal (Enterprise)

The Exec tab opens a real interactive shell inside a running container, the Docker equivalent of docker exec -it, no separate access to the host required. It's only available while the container is running.

Gated the same way as Kubernetes pod exec: available on the Enterprise plan, and shown as an upgrade prompt instead of a terminal on Free or Pro. Unlike Kubernetes, there's no separate RBAC opt-in for a Docker-mode agent: a Docker-connected agent's socket access already covers scaling, restarting, and rolling back containers, and exec is the same trust boundary as those, not a new one.

The agent's Docker socket mount is typically read-only at the filesystem level, but that doesn't limit what it can do over an already-open connection to the socket. Container scaling, restarts, rollbacks, and now exec all rely on this, so the real boundary here is your organization's plan tier and who has access to this dashboard, not the socket's mount flag.

Image details

Every container and pod's image links to its own detail page, provided the image has a content digest: the full image reference, digest, size, when it was built, and every other container or pod across your fleet currently running that same image. This is useful for finding every place a stale or vulnerable image is still deployed. Images are deduplicated by digest, so a base image shared across dozens of containers only shows up once. An image built locally rather than pulled from or pushed to a registry has no digest, so its name shows as plain text instead of a link.

Vulnerability scanning

Each image's detail page has a Vulnerabilities section listing known CVEs affecting it: severity, the affected package, the installed version, and the version that fixes it, sorted with the most severe findings first. Click Scan now to run a fresh scan; results are cached per image digest, so every container or pod running the same image shares the same scan result.

Scanning requires a scanner to be configured first, under Settings > Vulnerability Scanner. Three scanners are supported:

Trivy: trivy server's built-in server mode only does vulnerability-DB matching for its own CLI, not a remote scan by image name, so this points at a small HTTP wrapper you run around the trivy CLI instead.
Grype: Grype has no server mode of its own, so this points at a small HTTP wrapper you run around the grype CLI, not at Grype directly.
Snyk: uses Snyk's own cloud API with your account's API token. No endpoint needed.

API tokens are never shown again once saved; the settings page only confirms whether one is configured.

Volume browsing (Enterprise)

Every volume mount on a container or pod's detail page has a Browse action that opens a Docker-Desktop-style file browser for that mount: a breadcrumb showing the current path, and a sortable table of names, sizes, permissions, and modified times. Click a folder to go deeper; there's no download or edit action in this pass, browsing only.

Gated the same way as Exec: available on the Enterprise plan, and it runs over the same underlying capability as Exec (a command executed inside the container), so it needs the same RBAC opt-in on Kubernetes-mode agents. If the target container has no shell at all (a distroless or scratch-based image), browsing that volume shows a clear "no shell available in this container" message instead of an empty folder.