DockLog vs K9s

K9s is what platform engineers reach for. v0.51.x in 2026, Pulse and XRay cluster views, CRDs, plugins with dynamic input fields, RBAC reverse-lookup, log tail, port-forward, scale, PVC tools, skins, HTTP benchmarks. All keyboard-driven for people who already have kubeconfig on disk and think in :pod.

DockLog is for everyone else: the app developer who needs staging pod logs, the contractor scoped to one namespace, on-call without cluster credentials on the phone, and the setup where Docker Compose and k3s share the same metal.

What K9s does better

• Deepest terminal coverage of Kubernetes resources
• Zero cluster-side deployment for the client, local binary, your kubeconfig
• RBAC introspection, who can do what, reverse lookup
• Fastest tool when you are the operator and live in the terminal
• No HTTP attack surface on the cluster from a DockLog deployment

If that's you, keep K9s. We still use it.

Where DockLog fits on Kubernetes

No kubeconfig on the client

K9s requires cluster credentials on every laptop. DockLog requires a URL and login. Developers tail staging/api-* without holding a ServiceAccount token that could list half the cluster if mis-scoped.

UI-level RBAC on top of cluster RBAC

The ServiceAccount or kubeconfig behind DockLog might reach three namespaces. User alice still only sees staging/worker-* in the UI. User bob gets read-only tails; on-call has can_restart when server gates allow it.

Second filter for shared staging clusters where minting per-developer Kubernetes Roles for every pod name feels like overkill.

Details: RBAC post.

Audit in the tool people actually use

API server audit logs are powerful, if you enabled them, retain them, and know where to search. DockLog records restarts, shells, and logins in SQLite for actions taken through the UI, the surface you gave to non-operators.

Docker on the same host

RUNTIME_MODE=both, one login for compose containers and cluster pods. K9s is K8s-only. k3s + compose on one VPS is common; unified scoping is rare in pure k8s tools.

K8s hub without cluster-admin GUI weight

Namespaces, pods, deployments, services, HPAs, events, logs, optional shell, enough for day-to-day app ops. We deliberately don't try to be every kubectl verb.

Alerts and mobile

K9s shows events if you're watching the terminal. DockLog pings Slack or Teams on K8s warnings, log matches, metric thresholds.

iOS native app is on the way; Mac/iPhone use the web UI until then.

Real scenarios

Scenario: platform engineer debugging a CRD controller

K9s plugins, CRD browsing, port-forward, scale. DockLog won't replace that depth. Use K9s.

Scenario: frontend dev needs staging API pod logs

Giving them a kubeconfig with list pods in three namespaces is workable but scary when mis-scoped. DockLog login with allowed_containers: staging/api-* is simpler to explain and revoke.

Scenario: contractor on shared staging cluster

Kubernetes RBAC per contractor per app gets tedious. DockLog's second filter on pod name patterns avoids minting a new Role every sprint.

Scenario: homelab k3s plus compose on one box

RUNTIME_MODE=both shows compose services and cluster pods under one gate. K9s ignores the compose side entirely. Similar hybrid story for Docker-only tools in DockLog vs Lazydocker.

Scenario: on-call paged about a CrashLoopBackOff

K9s is great if you're at a laptop with kubeconfig. DockLog alerts plus Android tail work when you're not. Walkthrough: Slack/Teams/Discord alerts.

Decision table

Deploy for Kubernetes

Homelab: mount kubeconfig on the host

services:
  docklog:
    image: aimldev/docklog:latest
    ports:
      - "8888:8000"
    environment:
      RUNTIME_MODE: kubernetes
      KUBECONFIG: /app/kube/config
      K8S_NAMESPACES: default,staging,production
      SECRET_KEY: ${SECRET_KEY}
      DB_PATH: /app/data/docklog.db
    volumes:
      - ~/.kube/config:/app/kube/config:ro
      - ./data:/app/data

Restrict K8S_NAMESPACES to what the instance should ever see. DockLog cannot show namespaces you did not list here, even if the kubeconfig could.

In-cluster: ServiceAccount, PVC, Ingress

ServiceAccount, PVC for docklog.db, Ingress with WebSocket upgrade. Full skeleton in K8s without Loki.

Example ServiceAccount scope (cluster admin should tighten this):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: docklog
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: docklog-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events", "namespaces"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]

Bind to namespaces you trust DockLog to reach. UI-level allowed_containers is the second fence for humans.

Hybrid host

environment:
  RUNTIME_MODE: both
  KUBECONFIG: /app/kube/config
volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - ~/.kube/config:/app/kube/config:ro

Troubleshooting

"DockLog shows no pods"

Check K8S_NAMESPACES includes the target namespace. Verify kubeconfig context points at the right cluster. In-cluster installs: confirm ServiceAccount RBAC allows list pods in that namespace.

"Developer sees pods they shouldn't"

Two layers: cluster RBAC behind DockLog (kubeconfig or ServiceAccount) and per-user allowed_containers in Admin. Fix the UI pattern first; if the cluster credential is too broad, narrow the ServiceAccount.

"Log stream stutters or drops"

WebSocket through Ingress needs upgrade headers and reasonable proxy timeouts. Same nginx pitfalls as Docker mode. Production proxy guide.

"K9s can restart deployments but DockLog can't"

Server gates: ALLOW_RESTART must be true. User needs can_restart. Cluster RBAC must allow patch on deployments if you expose scale/restart actions. K9s uses your personal kubeconfig permissions; DockLog uses the service account plus UI flags.

"We already have Loki for logs"

Loki keeps history; DockLog gets you to a live line faster with scoped access. Many teams run both. See DockLog vs Grafana/Loki.

When to pick which

Pick K9s when:

• You are the platform owner with kubeconfig on your machine
• You need CRDs, plugins, port-forward, and full resource navigation
• You want zero HTTP service deployed in or near the cluster
• Deep terminal fluency is already the team culture

Pick DockLog when:

• App developers, contractors, or clients need pod logs without cluster credentials
• You want UI-level scoping and audit on top of a shared staging cluster
• Docker Compose and Kubernetes share one host and one permission model
• On-call needs mobile tails or Slack/Teams alerts on K8s events

Pick both when:

• Platform team lives in K9s; everyone else gets DockLog. Standard split on multi-tenant staging clusters.

Split the room

Official guide: docklog.dev/guide/kubernetes. App setup: native apps post. Broader K8s monitoring context: kubernetes monitoring tools guide.