DockLog

Product Introduction

1. Definition: DockLog is a self-hosted, lightweight Docker observability platform and container management dashboard. It is deployed as a single Docker container and provides real-time log streaming, host resource monitoring, and container lifecycle control via a web interface, desktop application, or native Android app.
2. Core Value Proposition: DockLog solves the complexity of traditional logging stacks for Docker environments. It provides instant, real-time log visibility and workload management without requiring Elasticsearch, Fluentd, or multiple microservices, positioning itself as a simpler, faster path for developers, DevOps teams, and homelab enthusiasts needing immediate container insights.

Main Features

1. Real-Time Log Tailing via WebSockets: DockLog streams container stdout and stderr logs instantly to the browser using WebSocket connections, not polling. This implementation ensures low-latency log delivery with features like autoscroll, automatic reconnection, and timestamp integration. It connects directly to the Docker daemon via the mounted /var/run/docker.sock, eliminating the need for separate log collectors or sidecar containers.
2. Granular Role-Based Access Control (RBAC): The platform includes a built-in RBAC system that allows administrators to define per-user permissions using wildcards or regex patterns. This enables precise control over which containers specific users can view or manage, which is essential for environments where production and staging containers share the same host. User permissions are managed via a SQLite database in auth mode.
3. Integrated Host and Container Metrics: DockLog combines log monitoring with basic host resource metrics. It displays CPU and memory usage statistics for both the host machine and individual containers within the same dashboard, providing correlated signals without requiring a separate monitoring tool like Prometheus or Grafana.
4. Container Lifecycle Management and Interactive Shell: Beyond monitoring, DockLog allows users to start, stop, restart, and remove containers directly from the web UI. When permissions permit (ALLOW_SHELL flag), it also offers an optional in-browser terminal for interactive shell access into containers, streamlining debugging and operational tasks.
5. Lightweight Single-Container Deployment: The entire platform is packaged and deployed as a single Docker image (aimldev/docklog:latest). It has a minimal footprint, consuming approximately 30MB of RAM, making it suitable for deployment on small VPS instances or resource-constrained homelab servers. A deployment builder tool helps users generate customized docker run or Docker Compose commands.

Problems Solved

1. Pain Point: The "logging stack sprawl" problem. Setting up a comprehensive Docker logging solution (e.g., with ELK or Loki) involves installing and managing multiple services (collectors, aggregators, search engines, UIs), which is complex, resource-heavy, and time-consuming for small teams or individual developers who simply need to tail logs and check container status.
2. Target Audience: This product is designed for Docker Developers needing quick debug access to logs, DevOps and Platform Teams managing shared host environments who require simple but effective access controls, and Homelab Enthusiasts running self-hosted services who want a lightweight, privacy-focused observability tool that keeps data local.
3. Use Cases: Essential for quick container debugging during development cycles, monitoring containerized applications on a personal server, managing workloads on a multi-tenant Docker host using RBAC, and replacing complex logging pipelines when the primary need is real-time log viewing and basic container control.

Unique Advantages

1. Differentiation: DockLog differentiates itself from full logging stacks (like ELK) by being radically simpler and lighter. It is not a replacement for large-scale, durable log aggregation and analysis. Instead, it offers a faster path to actionable insights by focusing on the immediate, real-time needs of container log streaming and management without the operational overhead of a multi-service stack.
2. Key Innovation: The core innovation is the combination of real-time WebSocket log streaming, integrated host metrics, and container management controls within a single, zero-dependency container. Its ability to operate in a no-auth mode for instant local dashboards and its optional SQLite database for RBAC (avoiding mandatory external databases) are key technical differentiators that maximize deployment simplicity and reduce the barrier to entry for Docker observability.

Frequently Asked Questions (FAQ)

1. What are the system requirements to run DockLog? DockLog requires a Docker host with a running Docker daemon. It is deployed as a single container and needs access to the Docker socket (/var/run/docker.sock). It is highly lightweight, using only ~30MB of RAM, and can run on any Linux VPS or machine capable of running Docker.
2. How does DockLog authentication and RBAC work? DockLog can run in no-auth mode for a simple local dashboard or in auth mode which uses SQLite to store users and audit logs. In auth mode, administrators set ALLOW_* environment variables as global server permissions, and then assign specific can_* permissions to individual users for fine-grained control over container visibility and actions.
3. Can DockLog forward logs to other systems like Elasticsearch or Loki? DockLog is designed as a terminal for real-time log viewing, not as a log pipeline. It does not natively forward logs to external systems. Its purpose is to provide immediate access to logs via the dashboard, desktop, or mobile apps, making external forwarding unnecessary for its core use case.
4. Is there a way to use DockLog with a reverse proxy like Nginx? Yes. For secure deployment behind a reverse proxy, you should set the TRUST_PROXY=true environment variable in DockLog. This instructs the application to honor X-Forwarded-* headers from the proxy, ensuring correct IP addresses and protocol detection. You should also set CLIENT_ACCESS=strict and use a strong SECRET_KEY.