DockLog vs Portainer

Portainer is infrastructure software. Deploy stacks from Git, manage registries, Edge fleets, Kubernetes environments, users and teams across all of it. The log tab works for a quick peek. Nobody installs Portainer because the log tab is great.

DockLog is the inverse, ~30MB, one container, stdout/stderr is the product. Auth, per-user container patterns, intelligent alerts, and an audit log ship in the open-source MIT image. Portainer reserves granular RBAC and activity logs for Business Edition.

Portainer CE vs BE

This comparison comes up when someone already runs Portainer CE and hits the ceiling on access control.

CE is excellent for homelabs and small teams who need a GUI for Docker and basic K8s. It does not give you "this contractor only sees containers named acme-*."

BE adds real enterprise RBAC, AD integration, audit streaming to a SIEM, and a license line item. Fair if Portainer is your control plane everywhere. Heavy if you only wanted scoped log access on one $20 VPS.

What DockLog does that Portainer usually doesn't

Log-first UI

Portainer's log view lives inside a busy product, volumes, networks, stack editors, registry browsers. DockLog's entire UI is built around tail latency, multi-stream layout, level highlighting, and detail pages with metadata, ports, labels, and health. When debugging is most of your day, that focus matters.

Team RBAC without BE pricing

allowed_containers, wildcards, regex, Kubernetes namespace patterns, is in the free image. Server-side ALLOW_* gates plus per-user can_* flags control restart, delete, and shell independently.

Useful for the agency on shared metal who needs contractor → acme-* only and can't justify Portainer BE.

Audit in the open-source build

Who restarted prod-api at 2am? DockLog writes logins, lifecycle actions, shell sessions, and admin edits to SQLite when DB_PATH is set. Export or back up docklog.db for retention. Portainer CE has no equivalent; BE activity logs are solid but paid.

Alerts as a first-class feature

Rules on log content, Docker events, K8s warning events, and CPU/memory: scoped, throttled, severity-tagged, delivered to Slack, Teams, Discord, or a webhook. Portainer is not where teams typically configure "alert me when this container OOMs."

Walkthrough: Slack/Teams/Discord setup.

Native apps

Developers, clients, and on-call engineers get Android, Windows, and Linux apps that connect to your DockLog instance, live tails, pod logs, controls, device credential storage, optional biometrics. No Portainer account required on the phone.

Docker and Kubernetes under one gate

RUNTIME_MODE=both, same RBAC across compose containers on the socket and pods from kubeconfig. Common when k3s and compose share one VPS; not Portainer's primary mental model.

Lightweight enough to colocate

~30–50 MB RAM typical. Run DockLog beside Portainer on the same host: Portainer for deploys, DockLog for who can tail what.

Comparison at a glance

Real scenarios

Scenario: homelab, you deploy stacks and peek at logs

Portainer CE is a natural fit. You own the box, roles are simple, audit rarely matters. DockLog is optional unless you want alerts or a phone app.

Scenario: agency VPS, client isolation, no BE budget

Portainer CE cannot express "contractor sees only acme-* containers." BE pricing hurts on a single $40/month box. DockLog OSS does name-level scoping and audit without a license line item.

Scenario: enterprise with AD and SIEM requirements

Portainer BE wins on LDAP/OAuth and audit export to Syslog. DockLog is not trying to be your IdP or SIEM pipeline. Evaluate BE seriously if Portainer is already the control plane.

Scenario: on-call lives on a phone

Portainer's web UI works in a browser but is not built for tail-first mobile workflows. DockLog's Android app targets log pause/catch-up and local notifications. Native apps post.

Scenario: you need both deploy GUI and strict log boundaries

Run both. Portainer owns stacks; DockLog owns tails. We see this often. Neither replaces the other cleanly.

Decision table

Config examples

DockLog beside Portainer on one host

services:
  portainer:
    image: portainer/portainer-ce:latest
    ports:
      - "9000:9000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer-data:/data

  docklog:
    image: aimldev/docklog:latest
    ports:
      - "127.0.0.1:8888:8000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - docklog-data:/data
    environment:
      DB_PATH: /data/docklog.db
      SECRET_KEY: ${SECRET_KEY}
      ALLOW_RESTART: "true"
      ALLOW_DELETE: "false"

Expose DockLog through the same reverse proxy as Portainer with WebSocket support on /ws. Proxy guide.

Example user scoping for agency setup

In DockLog Admin, create contractor@client-a.com with:

• allowed_containers: acme-*
• can_restart: false
• can_shell: false

Create oncall@agency.com with:

• allowed_containers: * (or acme-*,beta-*)
• can_restart: true

Server keeps ALLOW_DELETE=false so delete never appears for anyone. Pattern details: RBAC guide.

Hybrid Docker + k3s

environment:
  RUNTIME_MODE: both
  KUBECONFIG: /app/kube/config
volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - ~/.kube/config:/app/kube/config:ro

Portainer can manage K8s environments too, but log RBAC across compose and pods in one free scoping model is DockLog's lane.

Troubleshooting

"We have Portainer CE but contractors see everything"

CE roles are Admin, Standard, Read-only at environment level, not container-name level. Upgrade to BE, split hosts, or add DockLog for log access boundaries.

"Two GUIs on docker.sock feels redundant"

It is, if one tool covers your job. Colocation makes sense when Portainer deploys and DockLog scopes tails. Socket read access is shared; each service enforces its own auth.

"Portainer logs are slow for multi-container debug"

DockLog's UI is tail-first: split streams, level highlighting, detail pages tuned for incident response. Portainer's log tab is fine for a quick peek, not a full shift of debugging.

"DockLog WebSocket fails behind the same proxy as Portainer"

Portainer and DockLog both need correct proxy config; DockLog is stricter about WebSocket upgrade on /api and /ws. Fix timeouts and headers per production deployment guide.

"Need centralized log search, not just tail"

Neither Portainer nor DockLog replaces Loki or a cloud log store. Pair a tail UI with retention later. DockLog vs Grafana/Loki.

When Portainer still wins

• Standardizing container management across many environments
• BE budget for AD, namespace RBAC, SIEM audit streaming
• Registry governance and GitOps as first-class requirements
• Full Kubernetes cluster administration GUI

When DockLog wins

• Logs and who may see them are the requirement, not the whole platform
• Audit + scoping without BE pricing
• On-call lives on a phone app, not a browser bookmark
• Hybrid Docker + K8s with one permission model

Running both

We see this often: Portainer owns deployments; DockLog owns log access for developers, clients, and on-call. Different layers.

docker run -d \
  --name docklog \
  -p 8888:8000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v docklog-data:/data \
  -e DB_PATH=/data/docklog.db \
  aimldev/docklog:latest

Put it on loopback behind the same nginx that serves Portainer if both are public. Reverse proxy notes apply to DockLog's WebSocket paths.

Portainer can own the plane. DockLog can own the tail, the boundaries, and the pocket.

Further reading: compose production setup, self-hosted monitoring on a budget, DockLog vs Dozzle for another lightweight log-focused comparison.