DockLog vs Dozzle

We run Dozzle on personal boxes sometimes. It deserves the hype.

As of mid-2026 it streams Docker logs in real time, charts CPU and memory, runs SQL over buffered lines in the browser (DuckDB), fires alerts to Slack, Discord, and ntfy, connects multiple hosts via agents, tails Kubernetes pods, and supports file-based auth with per-user container filters and action roles. Docker sponsors it as OSS. For a solo dev on a trusted LAN, it's still hard to argue against.

DockLog isn't trying to win that use case. We built it for the VPS where staging and prod share a kernel, where a contractor needs logs but not your redis container, and where someone will ask "who restarted that?" at 2am.

Where Dozzle is hard to beat

Setup is one container and a socket mount. You're tailing in seconds.

Agent mode is the big one for fleet people: several Docker hosts in one UI, TLS between agents. DockLog today is one instance per daemon, multi-host switching is on our roadmap, but not shipped yet. If your main pain is "five servers, one log dashboard," Dozzle is ahead.

The log UX is polished. Split-screen tails, regex search, fuzzy container names, SQL when you want to query what's already in the buffer. We didn't build an in-browser SQL engine; for ad-hoc analysis on live lines, Dozzle is better.

Dozzle also stays simpler when you truly don't need team features. Optional users.yml, fewer env vars, less to explain to a homelab friend.

What Dozzle added (and what we still do differently)

Dozzle isn't "no auth" anymore. You can set DOZZLE_AUTH_PROVIDER=simple, define users in YAML, attach container filters, and assign roles like shell, actions, download, or none. Forward-proxy mode works with Authelia and OAuth2 Proxy via headers. That's real access control.

Where DockLog still diverges:

Two-layer permissions

Dozzle roles describe what a user type can do. We split it twice:

1. Server gates, ALLOW_RESTART, ALLOW_DELETE, ALLOW_SHELL remove entire action classes from the UI until you explicitly enable them on the container.
2. Per-user flags, can_restart, can_delete, can_shell on top, per human in Admin → Users.

Example: on-call gets can_restart=true; contractor gets tails only. Both might be "users," but restart only appears for one of them. Admins are subject to the same server gates, if ALLOW_DELETE is unset, delete doesn't exist for anyone.

See the RBAC post for the full pattern.

Audit trail

Dozzle gates who can do what. DockLog also records who did what when auth and DB_PATH are on: logins, restarts, stops, deletes, shell sessions, admin edits. Stored in SQLite. Agencies and shared VPS operators ask for this more than homelab users.

One scope field for Docker and Kubernetes

allowed_containers accepts client-a-*, staging/*, or ^prod-api-\d+$ in one comma-separated field. Wildcards and raw regex (when the pattern contains ^ or $) live together.

RUNTIME_MODE=both puts compose containers on the host and pods in the cluster under one login and one permission vocabulary. Dozzle tails K8s pods now; it doesn't offer the same unified RBAC + deployments/HPAs/services hub we ship.

Broader alerts

Rules on log lines, Docker events (die, OOM, health check fail), Kubernetes warning events, and CPU/memory thresholds, per-rule scope, severity, throttling. Slack, Microsoft Teams, Discord, or any HTTPS webhook. Teams matters in corp setups where Dozzle's Slack/Discord/ntfy set isn't enough.

Metrics with history

Live CPU/RAM charts are table stakes. DockLog keeps about 30 days in SQLite, enough to answer "when did this start climbing?" without Prometheus.

Native apps

Dozzle is web-only. We ship Android (Google Play), Windows, and Linux clients at docklog.dev/app. They talk directly to your server, JWT, tail with pause/catch-up, pod logs, log export, optional PIN/biometrics, local notifications when a container dies. No DockLog cloud relay. iOS native is in progress; iPhone works in the browser today.

Side-by-side

Real scenarios

Solo homelab, trusted network, you want SQL on live logs → Dozzle.

Five Docker hosts, one pane of glass → Dozzle agents until we ship multi-host.

Shared agency VPS, client A must not see client B's containers, audit when someone restarts prod → DockLog.

On-call tails from Android without SSH → DockLog app.

Corp Slack/Teams alerting on OOM and K8s warning events → DockLog.

Homelab with compose and k3s on one box, one RBAC model for both → DockLog both mode.

Decision table

Config examples

Dozzle: quick homelab

services:
  dozzle:
    image: amir20/dozzle:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Add users.yml when friends need access. Dozzle docs cover agent TLS for multi-host.

DockLog: agency VPS with gates

services:
  docklog:
    image: aimldev/docklog:latest
    ports:
      - "127.0.0.1:8888:8000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - docklog-data:/data
    environment:
      DB_PATH: /data/docklog.db
      SECRET_KEY: ${SECRET_KEY}
      ALLOW_RESTART: "true"
      ALLOW_DELETE: "false"
      ALLOW_SHELL: "false"

Admin creates contractor@client.com with allowed_containers: client-a-*, all can_* false. On-call gets can_restart: true. Compose production setup for hardening patterns.

DockLog: hybrid compose + k3s

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

One login scopes both runtime types. Dozzle tails K8s pods but does not unify deployment/HPAs/services navigation the same way.

Dozzle simple auth snippet (illustrative)

# users.yml (Dozzle)
users:
  contractor:
    email: contractor@example.com
    name: Contractor
    password: ${HASHED_PASSWORD}
    filter: "client-a"
    roles: []

DockLog uses the admin UI for the same idea with separate can_restart flags per user.

Troubleshooting

"Dozzle agent won't connect host 2"

Check TLS certs, firewall between agent and central UI, and that the agent can reach docker.sock on the remote host. DockLog does not offer an agent mesh yet; run one instance per host or wait for roadmap multi-host.

"Contractor saw another client's containers in Dozzle"

Tighten filter in users.yml or move to DockLog regex scoping plus audit if boundaries are contractual.

"We need Teams alerts; Dozzle only has Slack"

DockLog supports Teams webhooks on alert rules. Alerts guide.

"DockLog missing SQL on logs"

By design. Use Dozzle for ad-hoc DuckDB on the buffer, or ship logs to Loki for real search. DockLog vs Grafana/Loki.

"WebSocket tails drop behind reverse proxy"

Both tools need WebSocket-friendly proxies. DockLog documents /ws explicitly in production deployment.

When to pick which

Pick Dozzle when:

• You are solo or fully trusted LAN
• Multi-host agent dashboard is the main requirement
• In-browser SQL on live buffered logs matters
• You want the lightest possible setup

Pick DockLog when:

• Shared VPS with client isolation and audit expectations
• Two-layer action gates (server ALLOW_* plus per-user can_*)
• Microsoft Teams or broader alert types (OOM, K8s events, CPU)
• Native mobile/desktop clients for on-call
• Compose and Kubernetes under one RBAC model

Pick neither alone when:

• You need months of indexed search (add Loki) or full infra GUI (consider Portainer)

Try DockLog on the same socket

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

Log in as admin / admin123, change the password, add a user with staging-* only, set ALLOW_RESTART=true but deny can_restart for contractors, install the app. If that workflow matches how your host runs, keep it. If you're alone on a trusted box, Dozzle is still fine.

Further reading: compose setup, native apps, RBAC patterns, why self-hosted log viewer, best docker monitoring tools 2026.