Container Platforms

Scope

The Docker, Podman, and Kubernetes panels require separate agent capabilities. The organization plan must include each selected feature.

These panels support common tasks. They do not replace docker, podman, kubectl, or Helm.

Docker

The agent connects to the Docker API socket. It can inspect and manage containers, images, volumes, and networks.

The agent also reads logs, statistics, daemon details, and Docker events.

EnderDash reads standard Docker Compose labels. If the labels contain project and service names, EnderDash groups the containers by these values.

Docker Compose

EnderDash finds Compose projects from container labels and saved project files. You can deploy a new project from YAML.

Managed files stay in .enderdash/docker/compose after down and agent restarts. Relative bind mounts resolve from this directory. Project actions require a compatible Compose CLI on the agent host.

Supported actions:

• up
• down
• build
• pull
• config

EnderDash sends the project details to the local CLI. These details include the project name, working directory, configuration files, and service names.

If the agent cannot use docker compose, project actions return an error that says the command is unavailable.

Podman

Podman support uses the versioned native Libpod API. It does not use the Docker compatibility API.

Set CONTAINER_HOST to select a Libpod endpoint. The agent also discovers standard rootless and rootful Podman sockets.

The Podman panel manages containers, pods, images, volumes, networks, events, exec sessions, and system pruning. Rootless Podman shows only its user's resources.

The panel also creates pods and containers, exposes container inspection and statistics, and manages image tags and network connections.

The agent negotiates the native Libpod API version. Podman 4 or newer is required.

Deployment controls support:

• podman kube play, down, and generate against the selected endpoint
• Quadlet file listing, saving, removal, and service start, stop, and restart
• Buildah image builds and pushes

Quadlet actions require Linux, systemd, and Podman on the agent host. Rootless units use the agent user's configuration directory and systemd session.

Rootful units use /etc/containers/systemd and require host permissions. Buildah uses the agent user's local image storage. It requires buildah.

Kubernetes Inventory

EnderDash can list and manage these 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

Select a custom resource in the CRD browser, or enter it manually. The agent uses the Kubernetes dynamic resource API.

Cluster RBAC must allow the required actions for the 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 sends the objects to the server. The server then validates them.

YAML diff compares the current resource with the server's dry-run response. It shows changed fields and ignores Kubernetes bookkeeping metadata.

Helm controls list releases, show status and history, install or upgrade charts, roll back revisions, and uninstall releases. They require helm.

Node drain and pod eviction require kubectl. Drain honors disruption budgets and requires explicit options for unmanaged pods and emptyDir deletion.

Port-forward listeners bind to loopback on the agent host. Access from your computer requires a separate tunnel. The dashboard displays the agent-side address.

Metrics and rollouts

The rollout view shows the desired, updated, ready, and available replica counts. This view supports Deployments, StatefulSets, and DaemonSets.

The metrics view reads node and pod usage from the Kubernetes metrics API. Most clusters provide this API through metrics-server.

Without a metrics provider, the view reports an API error. EnderDash does not estimate usage from pod specifications.

Kubernetes RBAC

Read-only inventory requires get, list, and usually watch. Allow these actions for each resource that EnderDash must show.

For custom resources, grant the verbs on the custom API group and resource plural.

Operator features need these RBAC actions:

If EnderDash only needs to observe the cluster, use the read-only manifests.

If EnderDash must change workloads, grant the required write permissions. The public base manifests and Helm cluster-admin mode grant wildcard access, not a narrowly scoped operator role. See Kubernetes installation.

Kubernetes credentials

The agent reads in-cluster service accounts or kubeconfig files. KUBECONFIG supports multiple files with first-file precedence for named entries.

Set ENDERDASH_KUBE_CONTEXT to choose the inventory context. Otherwise, the agent uses in-cluster credentials or the first configured current context.

Token files refresh on each request. Noninteractive exec credential plugins support tokens and, on the JVM agent, client certificates with expiration-based refresh.

The native agent supports token authentication and custom CAs. Client certificates and TLS server-name overrides require the JVM agent.

Helm and maintenance forms can select a context for that operation. Those tools use the agent user's kubeconfig and credentials.

Docker image and Swarm tools

Image controls support builds, authenticated pulls, pushes, archive loads and saves, imports, and container exports. These operations require the Docker CLI.

Build contexts and archive paths refer to the agent host. Registry login uses password standard input and the agent user's Docker credential configuration.

Swarm controls accept full service specifications and manage secrets, configs, and stacks. Stack operations require the Docker CLI and a Swarm manager.

Integration tests

The container integration workflow tests Docker, native Libpod, and Kubernetes separately against multiple versions. Each job creates an isolated backend.

Local integration tests require explicit opt-in environment variables:

These tests create temporary resources and remove them afterward. Use disposable backends for testing.