Dozzle: a live Docker log viewer in a 7 MB container

The problem Dozzle removes: tailing logs across many containers

If you run more than a couple of containers, reading logs means either `docker logs -f` in several terminals or shipping everything into a log platform. Dozzle sits between those options. It is a web application that attaches to the Docker socket and streams container output to the browser in real time. The README is explicit that it "doesn't store any log files" and is "designed purely for live log viewing." That single design decision explains both what it is good at and where it stops.

The intended user is someone operating containers who wants to see what a container is printing right now, without configuring an indexer, a retention policy or a storage backend. The README notes Dozzle has been tested with hundreds of containers, which is the scale it is aimed at: one host, or a few hosts through agent mode. It is not a log platform and does not pretend to be one.

How the live streaming works, and what the agent mode adds

Dozzle is written in Go and ships as a single binary. The repository layout shows `main.go` at the top level, an `internal/` tree for the server, a `proto/` and `protos/` pair for protobuf definitions, and a Vue frontend built by Vite into a `dist` directory that the Go binary serves. The Dockerfile confirms the split: a Node stage runs `pnpm build`, and a Go stage compiles the binary with the built assets copied in.

The data flow is direct. Dozzle reads the Docker socket, requests the log stream for a container, and pushes lines to the browser over a WebSocket connection; the `gorilla/websocket` dependency in `go.mod` is the transport. Nothing is buffered to disk. Because the server holds the socket connection, the browser never talks to the Docker daemon itself.

Agent mode extends this across hosts. Running the container with the `agent` argument starts a process that listens on port 7007, and a central Dozzle instance connects to that agent to pull its logs. The `examples/` directory contains `docker.agents.yml`, `docker.agents-with-certs.yml` and `setup-remote-agent.sh`, so the repository treats multi-host setups as a first-class scenario rather than an afterthought. Swarm mode is a separate switch: `DOZZLE_MODE=swarm` runs Dozzle as a global service so each node reports its own containers.

One detail worth knowing: the default images are built `FROM scratch` and contain only the binary. There is no shell inside. The README says the `alpine` variants exist for setups that bind-mount a shell wrapper over the entrypoint, naming Unraid's per-container Tailscale toggle as the common case.

Installing Dozzle and viewing your first container log

The README's quick start is a single `docker run` that mounts the Docker Unix socket and a named volume for Dozzle's own data:

docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock -v dozzle_data:/data -p 8080:8080 amir20/dozzle:latest

After this, the README states Dozzle is available at http://localhost:8080/. You should see a list of containers on the left and the log stream of the selected container on the right. The repository's own `docker-compose.yml` mounts the socket read-only (`/var/run/docker.sock:/var/run/docker.sock:ro`), which is a tighter default than the quick-start command and worth copying.

The compose equivalent from the README:

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

For Swarm, the README gives a global service:

docker service create --name dozzle --env DOZZLE_MODE=swarm --mode global --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock -p 8080:8080 amir20/dozzle:latest

And for multi-host monitoring, an agent listens on 7007:

docker run -v /var/run/docker.sock:/var/run/docker.sock -p 7007:7007 amir20/dozzle:latest agent

On Podman the socket path differs. The README instructs you to check `podman info` for a `remoteSocket` entry, then run against that path:

podman run --volume=/run/user/1000/podman/podman.sock:/var/run/docker.sock -d -p 8080:8080 docker.io/amir20/dozzle:latest

Podman does not generate an engine-id, so the README says to create a file named `engine-id` under `/var/lib/docker` containing a UUID, for example via `uuidgen > engine-id`, to avoid `host not found` errors.

Where Dozzle stops: no history, no offline search

The most important limitation is stated by the project itself. The README says Dozzle "doesn't support offline searching" and points to Loggly, Papertrail and Kibana as better suited for full search capabilities. If a container restarts and you want to know what it printed an hour ago, Dozzle cannot tell you. The stream is live; when the browser disconnects, the view is gone.

The second constraint is the Docker socket. Mounting `/var/run/docker.sock` gives the container control over the Docker daemon, which is effectively root on the host. The repository's compose file mounts it read-only, and that is the sensible default, but the README's quick-start command does not. Anyone copying the fastest path is granting more than they need.

The third is version support. Dozzle requires Docker Engine 19.03 or newer (API version 1.40+); the README states older daemons are not supported by the underlying Docker SDK. On a long-lived host that has not been upgraded, Dozzle will not connect.

Finally, the quick-start exposes port 8080 with no authentication. The README documents authentication and forward proxy authorization as advanced options, and the repository has `examples/users.yml` and a `docker.swarm.auth.yml` example, but the default path is open. Running that command on a host with a public interface is a mistake.

Dozzle compared with Grafana, Loki and Portainer

The searches people run around this project are mostly comparisons, so the differences are worth stating plainly. Dozzle is a viewer, not a store.

Grafana with Loki is the opposite architecture. Loki ingests and indexes log lines into a backend, and Grafana queries that backend. You get history, retention windows and cross-service queries, and you pay for a storage layer, ingestion configuration and the operational work of keeping it running. Dozzle has none of that because it keeps nothing. If your question is "what happened at 03:00 last Tuesday," Loki is the right answer and Dozzle is not.

Portainer overlaps on the Docker socket and the web UI, but its scope is container management: starting, stopping, inspecting and editing stacks. Log viewing is one panel among many. Dozzle does one of those things and adds log-specific features the README lists: fuzzy search over container names, regex search, SQL queries against logs, split screen for multiple logs, and live CPU and memory stats. The SQL search is backed by DuckDB compiled to WebAssembly, visible in `package.json` as the `@duckdb/duckdb-wasm` dependency. That queries the lines already in the browser session, not a stored archive.

So the choice is not which tool is better. It is whether you need retention. Dozzle assumes you do not.

Maintenance, image tags and what the MIT licence means here

The repository is not archived, and the last push was on 2026-08-28, the same day as the v10.7.5 release. The release cadence visible in the recent list is roughly weekly, with v10.7.3, v10.7.4 and v10.7.5 all landing in August 2026.

Upgrade cost depends almost entirely on which tag you pin. The README's tag table is unusually clear about this. `latest` moves on every release. `v10` picks up new features within the major version. `v10.6` picks up bug fixes only within that minor. An exact tag such as `v10.6.15` is the reproducible choice. The README advises avoiding `latest` and `master` in production, and `master` is described as unreleased and unstable, built on every push. There are also `pr-1234` tags for testing a fix before it ships, which is a practical way to validate a patch against your own setup.

Because Dozzle stores no logs, an upgrade does not migrate data. The named `dozzle_data` volume holds Dozzle's own state, not log history. The main thing to re-check after a version bump is authentication configuration if you use `DOZZLE_AUTH_PROVIDER=simple`, since that is where a breaking change would bite.

The project is MIT licensed. That permits commercial use and modification, and the repository includes the LICENSE file and a MAJOR_VERSIONS.md document that describes the project's own versioning policy. Nothing here is legal advice; if you redistribute Dozzle inside a product, read the LICENSE text and the SECURITY.md file yourself.

Editorial conclusion

Adopt Dozzle if you run a handful of Docker hosts and want a browser tab that shows live container output without shipping logs anywhere. Skip it if you need to search history, because the README states it does not support offline searching and stores no log files. Before rolling it out, verify two things: that your Docker Engine is 19.03 or newer, since the underlying SDK drops older daemons, and whether port 8080 is reachable from anywhere you do not control, because the quick-start command exposes it without authentication. Pin an exact tag such as v10.6.15 rather than latest.

Frequently asked questions

Official sources

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