Container Platforms

Scope

The Containers panel appears when the connected agent exposes container management and the organization plan includes container management. It supports common day-to-day operations for Docker-compatible hosts and Kubernetes clusters, but it is not a full replacement for native tools such as docker, podman, kubectl, or Helm.

Docker

Docker support uses the Docker API socket available to the agent. The agent can inspect and operate on containers, stream logs and stats, manage images, volumes, and networks, inspect daemon details, read Docker events, and create Minecraft server presets.

Compose-aware container views use standard Docker Compose labels. When labels include the Compose project and service names, EnderDash groups those containers by project and service.

Docker Compose

EnderDash discovers Compose projects from labels on existing containers. A project can be controlled from the Compose projects view when the agent host has a compatible Compose CLI available.

Supported actions:

• up
• down
• build
• pull
• config

EnderDash passes discovered project metadata to the local CLI, including project name, working directory, config files, and service name when available. If neither docker compose nor podman compose is available in the agent environment, Compose project actions fail with a command availability error.

Podman

Podman support uses the Docker-compatible Podman API socket. Rootless Podman exposes only the containers owned by that user, so the dashboard may show fewer containers than a rootful host view.

EnderDash does not manage native Podman concepts that are not represented through the Docker-compatible API, including Podman pods, Quadlet units, Buildah workflows, and podman kube generated resources.

Kubernetes Inventory

EnderDash can list and operate on common Kubernetes resources:

• pods, deployments, services, nodes, and events
• StatefulSets, DaemonSets, ReplicaSets, Jobs, and CronJobs
• Ingresses, PVCs, PVs, HPAs, ConfigMaps, Secrets, and namespaces
• ServiceAccounts, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, NetworkPolicies, and StorageClasses
• CRDs and custom resources by API group, version, and plural resource name

Custom resources can be selected from the CRD browser or entered manually. The agent lists and inspects matching objects through the Kubernetes dynamic resource API, so cluster RBAC must grant the relevant verbs for that API group and resource plural.

Kubernetes Operations

Supported Kubernetes operations include:

• pod logs, pod exec, port-forward sessions, and debug containers
• deployment restarts, deployment undo, and workload scale actions
• StatefulSet scale and restart actions
• DaemonSet restart actions
• CronJob suspend, resume, and manual trigger actions
• pod, ConfigMap, Secret, PVC, and selected workload deletes
• node cordon and uncordon
• YAML dry-run, diff, apply, and delete

YAML apply uses server-side apply. YAML dry-run validates the submitted objects with server-side dry-run. YAML diff shells out to kubectl diff -f -, so the agent host or agent image must include kubectl and the same Kubernetes credentials must be usable by that command.

Metrics And Rollouts

The rollout view summarizes Deployment, StatefulSet, and DaemonSet status with desired, updated, ready, and available replica counts.

The metrics view reads node and pod usage from the Kubernetes metrics API. Most clusters provide this through metrics-server. If metrics-server or an equivalent API provider is not installed, the metrics view reports an API error instead of estimating usage from pod specs.

Kubernetes RBAC

Read-only inventory needs get, list, and usually watch for the resources you want to display. Custom resources need those verbs on the custom API group and plural resource name.

Operator actions need only the verbs for the actions you enable. Common examples:

Use the read-only manifests when EnderDash should only observe the cluster. Use operator RBAC only for clusters where the dashboard should mutate workloads or create Minecraft server presets.

Not Native Panels

These workflows remain outside native EnderDash container panels:

• Helm release management
• Podman pods and Quadlet lifecycle management
• Buildah-specific image build flows
• podman kube workflows
• arbitrary Kubernetes API features not represented by the inventory, custom resource, or YAML views

Use the platform-native tool for those tasks.