Dozzle
Live Docker log viewer in the browser that stores nothing
Dozzle attaches to the Docker API and streams container logs into a browser tab, with fuzzy container search, regex and SQL filtering, split panes and live CPU and memory readouts. It is a viewer, not a log store: it keeps no logs of its own and shows only what your Docker logging driver still has.
Our verdict on Dozzle#
Start here: Dozzle retains nothing. It is docker logs -f with a good interface, so what you can read is exactly what the logging driver still holds on disk, and docker rm on a container takes its logs with it. That is the whole design, and it is why the image is around 7 MB and the process idles in the teens of megabytes. In practice it replaces sshing into a box to tail a container, which is what most people actually do all day, and v10 added SQL queries and notification rules over the live stream. What it will never do is answer 'what did this log say last Tuesday'. If you need that, you need Loki or an equivalent, and Dozzle is not a stepping stone to one. The other thing to fix on day one is Docker log rotation, since Dozzle shows you unbounded json-file logs but does nothing about them.
Who Dozzle is for#
Choose it if
- Anyone who currently sshes into a server to run
docker logs -fseveral times a day - Debugging a compose stack where you want two containers' output side by side
- A small server where a full log pipeline would cost more RAM than the services it watches
- Multi-host setups where agent mode gives one tab across several Docker daemons
Look elsewhere if
- You need to search or alert on logs from last week; nothing is retained or indexed
- You need audit-grade retention for compliance, which requires a real log store
- You cannot expose the Docker socket to a web-facing container, even through a proxy
What running it actually looks like#
One container, one mount: /var/run/docker.sock, plus an optional /data volume and port 8080. The default images are built FROM scratch and contain only the binary, so there is no shell inside for debugging; an alpine variant exists for platforms that need one. Agent mode runs the same image with the agent argument on port 7007, and the main instance connects to it over TLS with self-signed certificates it generates itself, so both sides need the same certificates only if you expose that port outside a private network. Podman works but needs the remote socket enabled and a fake engine-id file. Nothing to migrate on upgrade, since there is nothing to migrate.
Resource profile#
- Memory
- 15 MB idle, around 40 MB in ordinary use. The default image is `FROM scratch` and about 7 MB compressed. Memory grows with the number of log streams open in browser tabs, not with how much has been logged.
- CPU and acceleration
- Streaming is nearly free; regex or SQL search across many containers at once is what makes it work, and it does that work per request rather than against an index.
- Storage growth
- Dozzle writes nothing except a few KB in `/data`. Your actual log storage is Docker's, under `/var/lib/docker/containers`, and it is unbounded unless you configure rotation.
- Operational load
- 1 of 5, Set and forget. One container, one socket mount, no database, no state worth losing. Upgrades are a tag bump and a restart, and the worst outcome of a bad upgrade is that you cannot read logs for five minutes.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Almost nothing to back up. /data holds users.yml for simple auth, notification rules and destinations, and per-user UI settings, all of which are a few kilobytes and easy to recreate. There is no log database, no index and no cache. The data that matters is Docker's own: the json files under /var/lib/docker/containers, which your backup strategy probably excludes on purpose. If you want log history to survive, that is a Docker daemon configuration question (max-size and max-file), or a job for a real log shipper, not something to solve in Dozzle.
Derived backup shape
File copy. Copy the config and data directories. Safe while running for anything that writes atomically.
Traps and surprises#
Nothing is retained, and container removal wipes history
Dozzle reads the live log stream and the driver's on-disk file. Recreate a container with docker compose up -d after an image update and the old container's logs are gone with it, including whatever explained the crash you are investigating. Copy anything you need out of the browser before recreating, or ship logs somewhere durable if the answer matters later.
Unbounded json-file logs fill the disk
Docker's default json-file driver has no size limit. A chatty container can write tens of gigabytes and take the host's root filesystem down, and Dozzle will cheerfully display it until the moment the disk fills. Set log-opts max-size and max-file in /etc/docker/daemon.json or per service in compose. This is the single most useful thing Dozzle will teach you about your stack.
Socket access is root on the host
Mounting /var/run/docker.sock gives the container the ability to start privileged containers, which is host root by another name. Put Dozzle behind authentication, bind it to a private interface, and consider a read-only socket proxy. Note the documented limit: you cannot put a socket proxy in front of a Dozzle agent, so agent mode needs the real socket.
Remote logging drivers rely on dual logging
If a container ships logs to splunk, fluentd or awslogs, Dozzle reads Docker's local dual-logging cache rather than the remote destination. That cache defaults to five rotated files of 20 MB per container, so what you see is a recent window, not the full stream your aggregator has. Containers on drivers that predate Engine 20.10 behavior may show an empty view instead.
Analytics are on by default
Dozzle sends anonymous configuration usage data to Google Analytics unless you pass --no-analytics or the matching environment variable. The project is open about it and publishes the dashboard, but it is outbound traffic from a container many people run on an isolated network. Add the flag if your firewall rules or your principles say containers should not phone out.
Specifications#
- Category
- Monitoring and observability
- Licence
- MIT (Permissive)
- Written in
- Go / Vue
- First release
- 2018
- Maturity
- Mature
- Datastore
- None for logs; a small /data directory for users and UI settings
- Default ports
8080,7007- Ships as
- docker, docker swarm service
- arm64 builds
- Yes
- Identity
- Trusted proxy header. Either a bcrypt `users.yml` file for local accounts, or forward-proxy mode trusting `Remote-User`, `Remote-Email` and `Remote-Name` from Authelia, oauth2-proxy or Cloudflare Access. No native OIDC.
- Replaces
- Papertrail, Loggly, Datadog Logs, Portainer log view
- Project site
- dozzle.dev
- Source
- github.com/amir20/dozzle
- Documentation
- dozzle.dev/guide/getting-started
Alternatives to Dozzle#
Everything else in monitoring and observability, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Beszel | 1, Set and forget | 40 MB | MIT |
| Gatus | 1, Set and forget | 25 MB | Apache-2.0 |
| Grafana | 2, Light | 150 MB | AGPL-3.0-only |
| Netdata | 2, Light | 150 MB | GPL-3.0-or-later (agent); dashboard UI under NCUL1 |
| Uptime Kuma | 2, Light | 120 MB | MIT |
| Prometheus | 3, Moderate | 150 MB | Apache-2.0 |
Where Dozzle comes up elsewhere#
Head to head
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.