The Problem: Container Logs Shouldn’t Require a PhD
I run a homelab. Docker Compose stacks, n8n workflows, MCP servers, the usual self-hosted chaos. And every time something breaks, I’m SSH’d into my Mac Mini, running docker logs container_name | grep error like it’s 1997.
Meanwhile, enterprise ops teams get Datadog and Splunk. Self-hosters get… the terminal. Or worse, bloated monitoring stacks that need their own monitoring.
I wanted something in between: a lightweight web UI that shows me container logs without requiring Elasticsearch, Prometheus, and a degree in YAML archaeology.
So I built StdOut.
What StdOut Actually Does
StdOut is a single-container log viewer for Docker environments. It does three things:
- Lists your running containers — all of them, with status and uptime
- Streams logs in real-time — pick a container, see stdout/stderr as it happens
- Searches logs — grep-style filtering without touching the command line
That’s it. No metrics. No alerts. No Grafana dashboards. Just logs, fast.
It mounts your Docker socket (read-only), exposes a web interface, and gets out of your way. If you’re already running Portainer or Dockge, think of this as the log tab you actually want to use.
Why I Didn’t Just Use [Insert Tool Here]
Portainer? Great for container management. Terrible for reading logs. The UI truncates output, scrolling is janky, and searching means exporting to a file.
Dozzle? Closer. But it tries to be more than a log viewer — badges, filters, multi-host setups. I wanted something leaner.
Dockge? Excellent for managing Compose stacks. Still not a log-focused tool.
Loki + Promtail + Grafana? Overkill. You’re configuring retention policies before you’ve fixed the thing that’s actually broken.
I wanted a tool that fits between “SSH and grep” and “enterprise observability stack.” StdOut is that tool.
How It Works (The Technical Bits)
StdOut is a Go binary that:
- Connects to Docker’s API via
/var/run/docker.sock - Streams container logs using the Docker SDK’s log-following API
- Serves a single-page web UI built with vanilla HTML/CSS/JS
- Keeps no state — your logs stay in Docker, where they belong
The container itself is 15MB. No database. No Redis. No Node.js runtime inflating the image to 200MB.
You deploy it with one Docker Compose block:
services:
stdout:
image: seayniclabs/stdout:latest
container_name: stdout
ports:
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: unless-stopped
That’s it. No environment variables. No config files. It just works.
If you’re paranoid about socket access (you should be), run it in a network with only the containers you want to monitor. Or put it behind Cloudflare Zero Trust and lock it to your tailnet.
What I’m Using It For
Every morning, I check my n8n automations. Some workflows fail silently. With StdOut, I open a browser tab, filter for error, and know in 10 seconds if something’s broken.
When I’m testing MCP servers, I run them in Docker and watch the logs in real-time. No switching between terminal tabs. No losing scroll position.
When a friend asks “why is my Pi-hole acting weird,” I send them StdOut. They install it, see the DNS query logs, and fix it themselves.
It’s not for everyone. If you’re running a hundred containers, you need something heavier. But if you’re a self-hoster with 10-20 services, this is the tool you didn’t know you needed.
Where It’s Going
Version 1.0 is intentionally minimal. It does one thing well. But there are obvious next steps:
- Log retention: search historical logs without needing a separate logging driver
- Multi-host support: manage logs from multiple Docker hosts in one UI
- Webhooks: trigger alerts when certain log patterns appear
- Docker Compose integration: show logs for all services in a stack, grouped
I’m building this in public. If you self-host, give it a try. If it saves you one SSH session, it’s done its job.
Try It Now
StdOut is free, open-source, and available at seayniclabs.com.
If you’re on r/selfhosted or Hacker News and thinking “I would’ve built this differently” — good. Fork it. Send a PR. Or just tell me what’s broken.
The point isn’t to replace your entire observability stack. The point is to make logs suck less for people who just want to ship side projects without becoming SREs.
Now go deploy it. Your future self will thank you.