Dozzle: A lightweight live log viewer for Docker, Swarm, and Kubernetes

What Dozzle is for and who should use it

Dozzle solves a narrow problem: watching container logs as they are generated. It is a web application that connects to the Docker socket and streams log output to a browser. The README is explicit that it does not store any log files. That makes it a live monitoring tool, not a log management platform. The intended audience is developers and operators who want to tail logs across many containers without installing a heavier stack. It supports Docker, Swarm, and Kubernetes, and it can monitor multiple hosts through agent mode. If you are debugging a service in real time, Dozzle gives you a quick view. If you need to answer 'what happened at 3 AM yesterday', it is the wrong tool. The README names Loggly, Papertrail, and Kibana as better suited for full search capabilities.

How Dozzle works: socket access, streaming, and no storage

Dozzle runs as a single container that mounts the Docker Unix socket. It uses the Docker SDK to communicate with the daemon. The README says it requires Docker Engine 19.03 or newer, which corresponds to API version 1.40 or later. The application streams logs from the daemon to the browser over a web interface. Because it does not persist logs, the memory footprint stays small. The README describes it as a 7 MB compressed image built from scratch, containing only the binary. The data flow is simple: the daemon pushes log lines to Dozzle, and Dozzle forwards them to connected clients. There is no ingestion pipeline, no index, no storage layer. That is the core trade-off. You get speed and simplicity, but you lose the ability to go back in time beyond what the Docker daemon itself buffers.

Getting it running: Docker, Compose, Swarm, and agent mode

The README gives concrete commands for several deployment modes. The simplest Docker run mounts the socket and a data volume: docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock -v dozzle_data:/data -p 8080:8080 amir20/dozzle:latest. The data volume is for Dozzle's own state, not for logs. A Docker Compose example is also provided, with the same socket mount and port mapping. For Swarm, the README shows a global service creation command that sets DOZZLE_MODE=swarm and mounts the socket. Agent mode is started by passing the agent argument to the image: docker run -v /var/run/docker.sock:/var/run/docker.sock -p 7007:7007 amir20/dozzle:latest agent. That agent listens on port 7007 and can be used to monitor multiple hosts. The README also notes that Dozzle works with Colima and Podman, but Podman requires extra setup.

Podman: a specific setup with a fake engine-id

Podman support is not automatic. The README explains that Podman is daemonless by default, so you must enable the remote socket. You can check with podman info and look for a remoteSocket key. If it is missing, you follow a socket activation tutorial. Once the socket exists, you run Dozzle with a volume mapping the Podman socket to /var/run/docker.sock. But there is a catch: Podman does not generate an engine-id like Docker does, which causes host not found errors. The fix is to create a file named engine-id under /var/lib/docker. The README says to place a UUID in that file, for example using uuidgen. This is a manual workaround that adds friction. If you are a Podman user, budget time for this step. It is a genuine failure mode that the project acknowledges and documents.

Features that matter: search, split screen, and authentication

Dozzle includes several features beyond basic log streaming. The README lists intelligent fuzzy search for container names, regex log search, and SQL query search. The SQL engine is a notable addition, since it lets you filter logs with structured queries rather than simple substring matches. The documentation at dozzle.dev covers the SQL engine in detail. Split screen lets you view multiple logs side by side, which is useful when debugging interactions between services. Live stats show memory and CPU usage per container. Multi-user authentication is supported, including forward proxy authorization. Dark mode is present. These features make Dozzle more than a dumb tail command. The fuzzy search and SQL filtering are the differentiators that justify a dedicated tool over a terminal alias.

Limitations: no offline search, no storage, and image tag cautions

The most important limitation is that Dozzle does not support offline searching. The README states this directly and points to Loggly, Papertrail, or Kibana for full search. If your workflow requires reviewing logs from yesterday, Dozzle will not help. Another limitation is that the default image is based on scratch, which means there is no shell inside the container. That is fine for most uses, but the README warns that some platforms, like Unraid, bind-mount a wrapper script over the entrypoint and need a shell. For those cases, you use the alpine variant. The README also advises against using the latest or master tags in production. latest moves on every release, and master is built on every push and is unreleased. You should pin a specific version like v10.7.5. The project is actively maintained, with releases in August 2026, but the versioning means you must be deliberate about tag selection.

Alternatives and how they differ in approach

The README names Loggly, Papertrail, and Kibana as alternatives for full search. The difference is fundamental. Dozzle is stateless and streams logs from the Docker socket. Loggly and Papertrail are cloud services that ingest logs, index them, and let you search historical data. Kibana, typically paired with Elasticsearch, also stores and indexes logs. Those tools have a larger footprint and require either a subscription or a self-hosted cluster. Dozzle gives up persistence to stay small. If you need a quick live view, Dozzle is lighter and easier to deploy. If you need retention, search across time, or aggregation from multiple sources, you need one of the heavier systems. The choice is not about features alone; it is about whether your workflow can tolerate a tool that forgets everything as soon as the stream passes.

Maintenance, licensing, and what to check before adopting

Dozzle is licensed under the MIT License, which is permissive and imposes few restrictions. The project is written in Go, and the primary distribution is a Docker image. The README lists image tags for exact versions, minor versions, and major versions, so you can control updates. The project is not archived and has recent releases, so it is actively maintained. However, the maintenance cost is on you: you must track new versions and decide when to upgrade. The README warns that the master tag is unstable, so you should never point a production deployment at it. Before adopting, verify your Docker daemon version meets the API 1.40 requirement. If you use Podman, plan for the socket and engine-id setup. The scratch image may not work on all platforms, so check whether you need the alpine variant. The documentation at dozzle.dev covers authentication and remote hosts, which you should review if you plan to expose Dozzle beyond localhost.

Editorial conclusion

Adopt Dozzle if you need a low-footprint, real-time log viewer for Docker, Swarm, or Kubernetes and you are comfortable with its stateless design. Do not adopt it if you need to search historical logs or run offline analytics; Loggly, Papertrail, or Kibana are better fits. Before deploying, verify that your Docker daemon runs API 1.40 or newer, and if you use Podman, confirm the remote socket is enabled and create the fake engine-id file as described in the README. Pin a specific version tag such as v10.7.5 rather than latest or master, and decide whether the default scratch image works with your platform or if you need the alpine variant. Dozzle is a focused tool: it streams logs, and it does that well, but it will not replace a log aggregation system.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes