A Late-Night Beszel Setup Exposed One Docker Monitoring Tradeoff

I opened henrygd/beszel during a short coding break because I wanted something lighter than a full observability stack for a few self-hosted servers. The pitch is attractive: a Go-based hub, small agents, historical metrics, Docker statistics, and alerts without immediately pulling in a database cluster or an entire dashboard ecosystem.

The first setup was pleasantly quick. The friction appeared when I enabled container-level statistics.

Beszel can read Docker metrics through the Docker socket, which means the agent needs access to /var/run/docker.sock. That is the familiar monitoring pattern, but it is also the part I would not hide behind a casual copy-paste command. A mounted Docker socket is effectively a privileged control path to the host, even when the container mount is read-only. Read-only prevents writes to the socket file; it does not magically turn the Docker API into harmless telemetry.

The minimal agent-side configuration looked like this:

services:
  beszel-agent:
    image: henrygd/beszel-agent
    restart: unless-stopped
    environment:
      HUB_URL: http://beszel:8090
      KEY: ${BESZEL_AGENT_KEY}
      TOKEN: ${BESZEL_AGENT_TOKEN}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

The hub itself can run separately with persistent application data:

services:
  beszel:
    image: henrygd/beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data

The exact KEY and TOKEN values should come from the hub’s agent onboarding flow rather than being invented in Compose. I also put the dashboard behind my existing reverse proxy, restricted access to the private network, and treated the Docker socket as an explicit security exception.

My takeaway: Beszel is a compelling fit for small fleets, homelabs, and internal infrastructure where low overhead matters. The rough edge is not the UI or the Go deployment—it is the privilege boundary around Docker monitoring. Review that mount, isolate the agent, and decide whether container stats justify the host-level access before rolling it across a team.