Why we built a self-hosted Docker log viewer

docker logs -f is fine until it isn't.

It breaks down the moment a contractor needs staging logs but not prod, or you're tailing from a phone, or three people want the same stream and someone's SSH session keeps dropping. At that point teams usually jump straight to Loki or a SaaS, which is a lot of machinery if all you needed was see the logs right now.

DockLog started as a fix for that specific annoyance.

Not a log warehouse

DockLog streams stdout/stderr live. It doesn't index six months of history or run LogQL. If you need that, keep Loki or your cloud provider's log store and use DockLog for day-to-day ops and incident tailing. We wrote up how that pairing works.

What one image handles on a small VPS (~30MB RAM typical):

• WebSocket log tailing, same feel as the terminal, in a browser or native app
• Per-user visibility via allowed_containers patterns (wildcards, regex, K8s namespaces)
• Optional alerts on log lines, Docker events, CPU/memory, K8s warning events
• Docker only, K8s only, or both (RUNTIME_MODE=both)
• Optional restart/stop/shell when server and user permissions allow
• Audit log when auth and DB_PATH are enabled

No Fluent Bit sidecar. No second frontend container.

The gap we were filling

That middle row is where most small teams live for years before anyone signs off on Loki in prod.

Where we've seen it stick

Homelabs and solo VPS setups: tail without SSH. Boring but real.

Small agencies on shared metal: client A gets acme-*, client B gets bravo-*, nobody sees each other's containers. RBAC patterns go deeper.

Staging clusters: K8s log access before anyone signs off on a full logging stack for prod. K8s mode mounts kubeconfig or runs in-cluster.

Hybrid hosts: Docker Compose for apps, k3s for something else, one UI with a runtime toggle.

On-call from a phone: Android, Windows, Linux apps connect to your server without SSH or mobile Safari wrestling with WebSockets.

Healthcheck debugging: docker health checks post pairs well with DockLog event alerts when containers flip unhealthy.

Typical week in the life

Monday: deploy staging, tail staging-api-* in the browser, no SSH key on the new intern's laptop.

Wednesday: client asks "did the worker restart?" Audit log answers if you enabled DB_PATH.

Friday 6pm: ERROR spike on prod, Slack alert fires, on-call opens native app, tails prod-api-*, restarts one container because ALLOW_RESTART is on for their user only.

That's the product scope. Not fleet-wide cost analytics.

What we said no to

Multi-cluster fleet dashboards (one instance per daemon today; multi-host is on the roadmap). OpenTelemetry traces. Long-term search across every service. SQL over months of logs. Those are different products.

DockLog is for the operator who needs to answer "what is this container printing at this second?" and sometimes "who restarted it?"

How it compares to the usual alternatives

Roundup of other tools: best Docker monitoring tools 2026, self-hosted container monitoring.

When not to use DockLog

• You need searchable logs from six months ago: keep Loki or cloud retention.
• You want one pane for fifteen Docker hosts today: Dozzle agents or wait for our multi-host work.
• You need full container lifecycle management: Portainer or your orchestrator UI.
• You have no trust boundary concern on a solo LAN: docker logs or Dozzle is simpler.

None of that is a knock. Wrong tool for the job is just wrong tool.

Socket access is still root

Mounting docker.sock or handing over a kubeconfig is the real privilege boundary. DockLog RBAC limits what the UI shows and which buttons work, but the instance itself still needs to run somewhere you trust.

Auth mode, ALLOW_* gates, and per-user can_* flags add layers on top. See the RBAC write-up when you invite other people.

Put it behind HTTPS before sharing a URL: reverse proxy post. Compose baseline: production compose.

Migration path (docker logs → DockLog → maybe Loki)

1. Smoke test with DISABLE_AUTH on a LAN (getting started).
2. Flip auth on, DB_PATH, change default password.
3. Add users and allowed_containers before sharing externally.
4. Put nginx/Caddy in front with TLS.
5. Add alerts for prod only.
6. Later, if retention becomes a requirement, add Loki for storage and keep DockLog for live tail. Loki comparison.

You don't have to rip anything out to try step 1.

Cost and ops reality

SaaS log platforms charge per gigabyte ingested. On a two-container VPS doing a few hundred MB/day, the bill is often "why are we paying this." Self-hosted DockLog is one container, one SQLite file, no ingest pipeline to babysit.

That's not anti-SaaS. It's "match spend to actual need." When retention and fleet search become requirements, add Loki and keep DockLog for the live tail.

Questions we get

"Can I search old logs?" Not across months. Tail live, grep in the stream, or pair with Loki.

"Is this production-ready?" We run it on prod-adjacent hosts with auth, TLS, RBAC, and backups. Your bar may differ; the security hardening guide is the checklist.

"Why not just Portainer?" If you want stacks, registries, and Git deploys, Portainer. If logs and delegated access are 90% of the job, lighter tooling wins. Comparison.

Try it on something real

Smoke test on a machine you trust:

docker run -d \
  --name docklog \
  -p 8888:8000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e DISABLE_AUTH=true \
  aimldev/docklog:latest

Use it during your next debug session. If it saves one SSH hop, flip on auth and read the compose setup post. Add alerts when you're ready to wake up to something meaningful, not staging noise.

MIT licensed, github.com/dockloghq/docklog if you want to poke at the source.