Welcome to the DockLog Blog
What this blog covers and where to start if you're new to DockLog.
We finally split the blog off from the main site.
docklog.dev stays the product page, features, guide, app downloads. blog.docklog.dev is where we put the longer stuff: compose files that actually made it to production, RBAC patterns that took a few tries to get right, nginx configs that kept WebSockets alive.
What goes here vs the guide
The guide on the main site should stay short and accurate. If a topic needs a war story, a full compose file, or an opinion on defaults, it lands here instead.
Think of the guide as reference. Think of the blog as "we ran this on a $6 VPS and here is what broke."
Where to start
If you are new to DockLog, this order works for most people:
- Install Docker Engine and Docker Compose on your VPS (official Docker docs, summarized here)
- Run the smoke test below on localhost
- Read Docker Compose for production before exposing anything to the internet
- Turn on auth and skim RBAC patterns if more than one person will log in
- Put TLS in front with reverse proxy hardening
- Add alerts when you are tired of manually refreshing the log view
If you came here from Google looking for tooling comparisons, jump to the roundups section below. If you run Kubernetes, start with K8s log tailing without Loki and the Kubernetes monitoring guide.
What's up so far
Product and deployment:
- Install Docker Engine and Install Docker Compose, official steps for Ubuntu/Debian VPS hosts
- Why we built native apps, Android, Windows, Linux, and what's coming on iOS
- Docker Compose setup, from
DISABLE_AUTHsmoke test to something you'd leave running - RBAC patterns, wildcards, namespaces, who can restart what
- Alerts to Slack/Teams/Discord, channels, rules, not waking up to noise
- Production behind a reverse proxy, TLS,
TRUST_PROXY, the WebSocket gotchas - K8s without Loki, kubeconfig, ingress, hybrid hosts
- Why self-hosted log viewer, the case for running your own tail instead of SaaS
Comparisons (honest notes on when we're not the right pick):
SEO roundups and guides (longer reads on problems DockLog touches):
- Best Docker monitoring tools 2026
- Docker log management
- Kubernetes monitoring tools
- Self-hosted container monitoring
- Docker health checks and monitoring
Env var reference and UI screenshots still live in the getting started guide.
Who each roundup is for
| Post | Read if you... |
|---|---|
| Docker monitoring tools 2026 | Want a map of viewers, metrics, and SaaS options |
| Docker log management | Need rotation, drivers, and a maturity path before ELK |
| Kubernetes monitoring | Run k3s or a small cluster and dislike YAML soup |
| Self-hosted monitoring | Have one VPS and a RAM budget |
| Health checks | Configure HEALTHCHECK and wonder what else you need |
Quick smoke test
On a machine you trust, with Docker running:
docker run -d \
--name docklog \
-p 8888:8000 \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DISABLE_AUTH=true \
aimldev/docklog:latestOpen http://localhost:8888 and tail a container. Container port is 8000 inside the image; 8888 on the host is just what we use in examples.
If that works, turn auth on before you share the URL with anyone else.
After the smoke test
Replace DISABLE_AUTH with a real SECRET_KEY and persistent DB_PATH. Mount a volume for /data so users survive container recreation. The compose production post has a copy-paste file with Caddy in front.
If logs connect but freeze after a minute, you are probably hitting a proxy without WebSocket upgrade. That is a nginx config issue, not a DockLog bug. Fix is in the reverse proxy post.
Common paths by role
Solo homelab: smoke test, then self-hosted monitoring, then Dozzle or DockLog comparison in vs Dozzle.
Small agency on one VPS: compose production, RBAC, log management.
Platform person with k3s: K8s log tailing, K8s monitoring guide, vs K9s.
On-call wanting phone access: native apps after the server side is solid.
RSS and updates
/rss.xml if you want new posts in a reader. Releases and issues stay on GitHub.
We add posts when users hit the same wall twice in support or issues. Comparisons get updated when a competitor ships something meaningful. Roundups get a pass when the landscape shifts (new defaults, deprecations, pricing changes).
Contributing topics
Got a topic that would help? Open an issue on GitHub with:
- What you were trying to do
- What you expected
- What actually happened (compose snippet, redacted URLs, log line)
We write about what people actually run into, not keyword filler. If your war story would save the next person an evening, we want to hear it.
A note on comparisons
We publish DockLog vs X posts because people search for them. We try to say when the other tool wins. If you are a solo dev on one machine, Lazydocker or Dozzle might be the better day-to-day choice. If you need cluster-wide admin, Portainer or K9s might fit. DockLog fits when you want self-hosted tail plus team permissions without running a logging stack.
The roundups link out to those comparisons so you do not have to read every post to pick a direction.
Staying current
DockLog server releases ship on GitHub. Mobile and desktop app builds ship on docklog-mobile releases. Blog posts reference versions at publish time; check release notes if something moved.
When a post mentions DISABLE_AUTH, RUNTIME_MODE, or ingress headers, cross-check the getting started guide for the current env var list. The guide wins on accuracy; the blog wins on context.
What we do not cover here
API reference, every env var default, and step-by-step UI clicks stay on docklog.dev. Security advisories and breaking changes land in GitHub releases first, then we backfill a blog post if the migration is non-obvious.
If you are evaluating DockLog against a hosted SaaS, read why self-hosted log viewer for the data-residency and cost framing before you read the feature comparisons.