Observability for my Docker Compose stack with Bull Board and Dozzle

The starting point
The decision
Why Bull Board is a separate container
Why Dozzle is enough
What I changed in the infrastructure
What this improved overall
All articles in the series

The starting point

I already had a working ingestion path. The extension sends a capture request, the backend creates a job in Redis, a worker processes it later, and Qdrant stores the result.

The problem was not the flow itself. It was visibility. If something went wrong between POST /ingest, Redis, the worker and Qdrant, I saw only the symptom. I had to collect logs and infer the queue state indirectly. That is exactly how a black box emerges.

The decision

I deliberately chose a small observability layer instead of a large monitoring platform. Its two components are Bull Board for the queue and Dozzle for logs.

Bull Board shows whether jobs are accepted, waiting, active, failed or completed. Dozzle shows container logs in the browser. Together, they cover exactly the places I actually investigate day to day.

I deliberately deferred OpenTelemetry and Jaeger. They would be interesting for end-to-end tracing, but would immediately require more instrumentation in the backend, worker and eventually elsewhere. For this step, I first wanted transparency with little change to the system.

Why Bull Board is a separate container

I could have mounted Bull Board directly in the backend. I decided against it because I wanted separate responsibilities.

A separate container has three advantages for me. First, I can start, restart or replace it independently. Second, the backend stays lean and focused on the API. Third, I see queue data separately from business logic and can debug faster when a job gets stuck.

Bull Board therefore connects to the same Redis queue as the worker, but runs as its own small application behind Traefik. It is directly accessible locally and additionally protected by an IP allowlist in production.

Why Dozzle is enough

For logs, I did not want to build a heavy stack. At this stage, a browser window showing container logs in real time is enough.

Dozzle has almost no operational overhead for this. It needs no database of its own, no retention logic and no additional indexing. I only mount the Docker socket read-only and can immediately switch between the backend, worker, Traefik and other services.

That is particularly useful during everyday debugging. If a capture gets stuck, I see the queue entry and log messages side by side. I do not first have to SSH into a VM to use docker logs.

What I changed in the infrastructure

I added the observability layer so that local development and production remain as similar as possible.

bull-board:
  build: ./bull-board
  networks:
    - traefik_net
    - internal_net
  labels:
    - 'traefik.enable=true'
    - 'traefik.http.routers.bull-board.rule=Host(`bull.localhost`)'

dozzle:
  image: amir20/dozzle:v8
  networks:
    - traefik_net
  labels:
    - 'traefik.enable=true'
    - 'traefik.http.routers.dozzle.rule=Host(`logs.localhost`)'

In production, both services still run through Traefik, but only through an allowed IP list. The architecture stays the same. Only access is controlled more tightly.

What this improved overall

The most important improvement is not the dashboard itself. It is having a traceable path.

I can see whether a job reached Redis at all. I can see whether a worker accepted it. I can inspect the corresponding logs. I can follow behavior in the same way locally and in production.

That significantly reduces the time needed to find the cause. I no longer search blindly across several containers, but follow the same flow as the data.

For me, this is the right kind of observability at this project stage. Not maximum complexity, but enough visibility to find failures faster and add new changes more safely.

Bull Board and Dozzle in the same Traefik stack

The graphic shows the same stack into which I added Bull Board and Dozzle. The point is not merely another tool, but a clear path from the extension to storage that I can operate in the same way locally and in production. The original graphic retains its German labels.

All articles in the series

Vision and system overview: Chrome Extension, RAG architecture and project background: Read article
Building a RAG system: Qdrant, embeddings and cosine similarity in TypeScript: Read article
AI provider abstraction: Ollama vs. OpenAI, interface design and no vendor lock-in: Read article
Chrome Extension MV3: Three isolated runtime contexts, message passing and Strategy Pattern: Read article
Docker Compose strategy: The override pattern, from local development to Azure: Read article
Ollama locally vs. Docker: The decision and its consequences: Read article
Ollama auto-pull entrypoint: Automated model setup at container startup: Read article
tsconfig and Vite: Node16 vs. bundler, and why Vite has its own rules: Read article
Load complete Instagram captions with MutationObserver: Read article
Chrome Extension foundation with health indicator and retry queue: Read article
Phase 2 features: Shadow DOM overlay, Tailwind v4 and duplicate detection: Read article
Race condition in platform detection: How a UI event breaks Instagram detection: Read article
Extracting PostId in two Instagram layouts: querySelector vs. ancestor traversal: Read article
Capture a complete Instagram carousel with MutationObserver: Lazy loading, observer-before-click and timeout fallback: Read article
Notes and tags when saving screenshots: Read article
Instagram keyboard shortcuts block Chrome Extension input: Read article
Lowercase normalization and duplicate detection in tag input: Read article
Zitadel Login V2 in Docker Compose with three hidden errors: Read article
PKCE OAuth in a Chrome MV3 extension: Read article
React frontend with react-oidc-context and Zitadel: Read article
Vite build-time environment variables in Docker: Read article
Event-driven ingestion with BullMQ and Redis: Read article
MinIO instead of Azurite: S3-compatible object storage locally and on Hetzner: Read article
access_token, id_token and the Userinfo endpoint: Which belongs where: Read article
Qdrant multi-tenancy with one collection per user: Read article
When backend and frontend know different types: Read article
Removing Zitadel bootstrap: Host header bug and manual setup: Read article
Backend code review with six problems fixed before launch: Read article
Traefik instead of NGINX: Reverse proxy for a growing Docker Compose stack: Read article
Two-layer rate limiting: Traefik and express-rate-limit with Redis: Read article
Implementing GDPR Article 17 correctly: Promise.allSettled and export batching: Read article
Embedding model lock-in: Why mxbai-embed-large is a permanent production decision: Read article
Docker volumes in production: Named volumes, bind mounts and the Hetzner volume approach: Read article
Two vulnerabilities before launch: Redis without authentication and an exposed Qdrant admin port: Read article
Traefik as the single entry point in the Docker Compose stack: Read article
Connecting Zitadel behind Traefik with issuer, JWKS and Login V2: Read article
Fixing the frontend when the nginx healthcheck fails on localhost: Read article
Observability for my Docker Compose stack with Bull Board and Dozzle: (this article)
Open the Qdrant dashboard securely with local Traefik and an SSH tunnel: Read article
Diagnosis of chunking failures despite tokenization: Read article
Why I set the chunk size to 1500 tokens: Read article
Splitting the embedding workflow into clear steps: Read article
Bringing chunking, storage and search back together: Read article
Capture Intake as a separate module, less orchestration in the Express endpoint: Read article