DockLog Ships One Image for Docker and Kubernetes Logs: What It Buys a Cluster API Fleet Over kubectl logs -f

Half a fleet is still docker-compose. The other half already migrated to Cluster-API-managed pods, because that's how migrations actually go — in pieces, over months, not in one weekend cutover. When something breaks at 2 a.m., the on-call engineer doesn't get to pick which half. They get to SSH into a Hetzner box for the compose services, then switch terminals and run kubectl logs -f against a completely different cluster for the rest, correlating timestamps by hand across two tools that have never heard of each other.

DockLog, an open-source log dashboard that shipped in 2026, ships as one container that can watch a Docker daemon, a Kubernetes cluster, or both from a single RUNTIME_MODE toggle — no separate builds, no picking a lane. That's a real answer to the mixed-fleet problem above, and it's worth being precise about exactly what it buys over hand-rolled kubectl logs loops, and — just as important — where its scope quietly stops, because "both" does not mean "the whole fleet." Here's the concrete accounting, plus where the line sits before a growing fleet needs a real log-aggregation stack instead.

What DockLog Actually Ships​

Per the project's GitHub repository and site, DockLog is a single Go binary with an embedded Vue frontend, MIT-licensed, and deliberately light:

• Mode switch via RUNTIME_MODE: docker (default), kubernetes, or both — one image, one env var, connecting to a Docker socket and/or a Kubernetes API from the same container.
• Kubernetes connection options: auto-detected in-cluster ServiceAccount, a mounted kubeconfig file, or explicit overrides (K8S_CONTEXT, K8S_API_SERVER, KUBECONFIG), plus a K8S_NAMESPACES allowlist to scope what a given instance can even see.
• RBAC with pattern matching: per-user rights on start/stop/restart/delete, expressed as wildcards (backend-*) or regex (^prod-.*$) rather than one entry per container or pod.
• Alerting via webhooks: Slack, Teams, Discord, or arbitrary HTTPS endpoints, triggered on log patterns, Docker/Kubernetes events, or CPU/memory thresholds — stored in SQLite, no external dependency to stand up.
• Audit logging of administrative actions, and host/container/pod CPU and memory stats alongside the log stream.
• Footprint: roughly 30–50 MB of RAM at idle, advertised throughput above 10,000 lines per second — light enough to run as a sidecar on the same box it's watching.

That puts it in the same category as Dozzle, the other widely-used self-hosted container log viewer, which also added a Kubernetes mode (k8s) for tailing pod logs instead of just Docker containers. The meaningful difference for a mixed fleet is that Dozzle's Kubernetes support is a mode you point a deployment at one cluster, the same way DockLog's is — neither tool was built to aggregate across many clusters at once. Dozzle is explicit that it doesn't store logs or collect metrics; it's a live viewer, not a retention layer. DockLog adds webhooks, RBAC, and an audit trail on top of that same live-tailing core, which is the part that actually matters for an operator-facing triage surface rather than a developer convenience tool.

The Fleet Gap: One Image, Not One Fleet​

Here's the finding worth stating plainly before anything else, because it's the part a skim of the feature list would miss: RUNTIME_MODE=both connects one DockLog container to one Docker daemon and one Kubernetes cluster. It is not a fleet-wide aggregator. Point it at a management cluster and it'll show you that cluster's pods; point a second instance at a workload cluster's kubeconfig and it'll show you that cluster's pods — as two separate dashboards, two separate URLs, two separate login sessions. The project's own roadmap lists "multi-host support" as planned, not shipped — there is currently no single DockLog pane that spans multiple Docker hosts or multiple Kubernetes clusters at once.

For an operator running a self-hosted PaaS on Cluster-API-managed infrastructure — where a single fleet might mean one management cluster plus several workload clusters, each hosting a slice of tenant apps, alongside a handful of docker-compose boxes that haven't migrated yet — that scope limit matters. DockLog collapses the within-one-cluster-or-host problem (the SSH-then-kubectl-then-different-SSH shuffle) into one screen. It does not collapse the across-clusters problem. An operator debugging "why is tenant X's app unreachable" without first knowing which of six clusters it landed on still needs either a routing convention (which cluster owns which tenant, kept elsewhere) or one DockLog instance per cluster, checked in sequence — the same context-switch DockLog was supposed to remove, just with a nicer UI at each stop instead of a raw terminal.

That's not a reason to skip it. It's a reason to scope the claim correctly: DockLog buys per-cluster and per-host incident triage that's genuinely better than raw CLI loops, at genuinely low operational cost. It does not buy fleet-wide log search, and treating a RUNTIME_MODE=both deployment as if it already covers the whole Cluster-API fleet is the mistake that turns a helpful tool into a false sense of coverage during an actual incident.

What It Actually Removes vs. kubectl logs -f Loops​

Scoped correctly — one DockLog instance per cluster or host group — the improvement over hand-rolled CLI tailing is concrete, not just aesthetic:

• No SSH-then-context-switch per host. A docker-compose box and a Kubernetes cluster today require two entirely different access paths (SSH + docker logs -f, versus a kubeconfig + kubectl logs -f). DockLog's both mode puts them behind the same web login.
• No unstructured search across a scrollback buffer. kubectl logs -f | grep against a live stream loses everything above your terminal's scrollback the moment you start typing a new search. A web UI with a persistent connection and pattern matching doesn't.
• No manual alerting. There's no equivalent of a webhook firing on a log pattern in a raw kubectl logs -f loop — that requires someone to be watching the terminal, or a separate tool bolted on. DockLog's webhook triggers (log pattern, restart count, resource threshold) mean the first signal of trouble doesn't depend on a human tailing a terminal at the right moment.
• No all-or-nothing access. kubectl access is typically all-or-nothing at the RBAC-role level for whoever holds the kubeconfig; DockLog's wildcard/regex per-user rules let a support engineer see and restart frontend-* containers without also holding delete rights on prod-database.
• No audit blind spot. A kubectl delete pod run from someone's laptop leaves a trace in the Kubernetes API server's audit log if you've configured one — which most self-hosted clusters haven't. DockLog's own audit trail exists by default the moment you deploy it.

That's a real, itemized reduction in the number of manual steps between "something's wrong" and "here's the log line that explains it" — genuinely the thing kubectl logs -f loops are worst at, especially for a support engineer who isn't the person who wrote the original deployment manifests.

Where Loki and Grafana Still Win​

None of the above is log aggregation, and DockLog doesn't claim to be. The distinction that matters: DockLog tails what's currently emitting, live, from whatever it's connected to; a stack like Loki paired with Grafana stores logs, indexes them, and lets you query across time ranges and — critically — across sources, with a real query language (LogQL) instead of a text filter on a live tail.

That capability comes with real operational weight, and it's worth being honest about the size of it rather than hand-waving "just run Loki." The Loki/Grafana/Tempo/Mimir (LGTM) stack means managing multiple deployments, configurations, and upgrades, each component with its own query language to learn, and — per that same sizing analysis — a platform team of fewer than three dedicated SREs will genuinely struggle to hold the observability layer itself at high uptime once workloads grow past a small footprint. On the other end, that same analysis found a single 4 vCPU / 8 GB RAM / 100 GB SSD VM can comfortably handle around 1 GB of logs per day and roughly 2,000 metric series — a real number, not a floor or a ceiling, and one that shifts with retention window and cardinality, but a useful anchor for what "small" means before the stack starts asking for dedicated headcount.

That's the actual trade: Loki-class aggregation buys retention beyond a container's lifetime, cross-cluster and cross-host query in one place, and structured search — capabilities DockLog's live-tail model doesn't have and isn't trying to have. It costs a multi-component system that needs someone who owns it. For a fleet with a couple of clusters and a handful of compose hosts, that cost is disproportionate to the problem. For a fleet where "which of our twelve clusters has this error" is a daily question, it stops being optional.

Where the Line Actually Sits​

Given both ends of that trade, a rough decision line, aimed at where most self-hosted PaaS operators sit rather than either extreme:

The pattern underneath that table: DockLog and tools like it aren't a smaller version of Loki, they're a different tool for a different job — live, low-friction, per-cluster incident triage instead of durable, cross-cluster search. A fleet doesn't "graduate" from one to the other so much as it eventually needs both, run side by side, each doing the part it's actually good at.

Bex.co is the open-source, AI-native alternative to Render — push a git repo, get a running HTTPS service on machines you own, with the underlying fleet managed by Cluster API instead of hand-rolled scripts. A per-cluster live-tail tool like DockLog is exactly the kind of low-overhead operator surface that fits alongside that model without requiring a full observability stack on day one. Star the repo on GitHub or deploy your first app today.

Sources​

• DockLog — project site.
• dockloghq/docklog — GitHub repository (RUNTIME_MODE, RBAC, webhooks, resource footprint, roadmap).
• DockLog on Product Hunt — launch listing.
• Dozzle — self-hosted Docker log viewer.
• Dozzle Kubernetes Support — k8s mode documentation.
• Grafana Loki Prometheus Stack: Production Monitoring for AI Systems — LGTM stack operational complexity and VM sizing figures.
• 10 Best Logging Tools in 2026 — Parseable, self-hosted logging tool landscape.