Run Dozzle for Simple Docker Log Viewing

Before you begin

• A Docker host running Engine 19.03 or newer.
• A place to keep the Dozzle stack, such as /opt/stacks/dozzle.
• A private access pattern or reverse proxy plan.
• Realistic expectations: Dozzle is a log viewer and lightweight debug surface, not a full logging retention platform.

Dozzle's current docs still recommend a Compose deployment that mounts /var/run/docker.sock plus a persistent /data volume, listens on port 8080, and leaves actions, shell access, and authentication disabled unless you explicitly turn them on.

Step 1: Create the Dozzle Compose stack

Create a directory for the stack and save this as compose.yaml:

mkdir -p /opt/stacks/dozzle
cd /opt/stacks/dozzle

services:
  dozzle:
    image: amir20/dozzle:latest
    restart: unless-stopped
    ports:
      - 127.0.0.1:8080:8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - dozzle_data:/data

volumes:
  dozzle_data:

The upstream example mounts the socket without :ro. Using a read-only mount is a safer starting point when you only want logs and do not plan to enable actions.

Step 2: Start and verify Dozzle

Bring up the stack:

docker compose up -d
docker compose ps

Then check the container logs:

docker logs dozzle --tail 100

Visit the service privately through SSH port forwarding or your private reverse proxy. You should see running containers and be able to follow their logs in real time.

Because Dozzle stores notification settings and similar UI data in /data, the named volume matters if you want those settings to survive container recreation.

Step 3: Add private access or simple auth

The safest baseline is to keep Dozzle reachable only on localhost and publish it through a private admin path.

If you need built-in authentication, add the provider setting:

services:
  dozzle:
    environment:
      - DOZZLE_AUTH_PROVIDER=simple

Dozzle's authentication docs also warn that if it is reachable from the public internet, you should protect it with authentication and keep actions and shell access off unless they are truly required.

Step 4: Use Dozzle without overexposing it

Dozzle works best for fast diagnosis tasks such as:

• Watching a container fail on startup
• Checking whether a reverse proxy is receiving requests
• Filtering logs during an app deploy
• Spotting repeated error bursts before deeper investigation

It is less suited for long-term retention, cross-host search at scale, or audit-grade historical analysis. If you need those, move into a dedicated logging stack later.

Step 5: Update and maintain the stack

Routine checks:

docker compose ps
docker logs dozzle --tail 50
docker volume ls | grep dozzle

To update:

cd /opt/stacks/dozzle
docker compose pull
docker compose up -d

If you later decide to enable authentication or remote agents, update one concern at a time and retest access after each change instead of toggling everything at once.

Rollback notes

Because Dozzle is operationally stateless apart from its data volume, rollback is simple: restore the previous image tag or revert the small Compose file change that broke access.

docker compose down
docker compose up -d

If you changed authentication settings and locked yourself out, review the mounted data volume and the exact environment values before recreating the container.

Troubleshooting

No containers appear in the UI.
Confirm the Docker socket is mounted at /var/run/docker.sock and that the container can read it.

Settings disappear after recreating the container.
Check that /data is backed by a named volume or host path instead of ephemeral storage.

Public users can reach the UI.
Change the port bind to localhost only or move access behind authenticated private networking immediately.

You want historical searching across weeks of logs.
That is beyond Dozzle's sweet spot. Add a real log pipeline rather than forcing this tool to become one.