henrygd

Tired of grepping journalctl logs to know if your server's alive? Beszel: Go hub + tiny agent, historical metrics, Docker container stats, alerts. MIT by hank (henrygd). henrygd/beszel #homelab #systemd

Beszel now groups containers by Compose project — your 40-container homelab becomes 6 rows If you run Beszel and more than a couple of Compose stacks, you know the container page: one long list where `immich_server`, `immich_machine_learning`, `immich_postgres` and `immich_redis` sit between unrelated things, sorted by whatever column you picked. There's no notion that those four are one deployment. I implemented that notion. PR is open here: beszel#2733 The agent reads `com.docker.compose.project` and `com.docker.compose.service` — labels Compose already sets on every container you've ever started with it. Nothing to configure, no labels to add, no env vars. Swarm's own labels take priority when present, which is where this started, but on a normal homelab host the Compose ones do all the work. What you get: - One row per project, with the containers folded underneath it. The row sums CPU, memory and network across the project, counts the containers, and shows the worst health in the group — so an unhealthy `postgres` surfaces at the project level instead of hiding four rows down. - Search finds a project by name: type `immich` and the whole stack stays, everything else goes. - Charts can draw one line per project instead of one per container. Twelve lines become four, and the four are the things you'd actually name out loud. - Containers you started with plain `docker run` keep their own row, unlabelled and ungrouped. They don't get swept into an "other" bucket. - If none of your containers has Compose labels, the page looks exactly as it does today. The grouping, the new columns and the chart selector all stay hidden. Status: the PR is open, the maintainers have reviewed an earlier slice of it, and it isn't merged. I ran the whole thing locally — hub and agent built from the branch, pointed at a real Docker host with several Compose projects — but a multi-node Swarm I don't have, so that side is less exercised. Screenshots below: the list before, the same data grouped, and a project expanded over its services.

Beszel : une plateforme Open Source de supervision des serveurs, conçue pour être légère, simple à installer et peu gourmande en ressources. 👉 henrygd/beszel

Beszel : une plateforme Open Source de supervision des serveurs, conçue pour être légère, simple à installer et peu gourmande en ressources. 👉 henrygd/beszel t.co

Problem: Had been nerve-racking to track server & service health on machines using different platforms and in different geolocations. Solution: Consolidate everything using one Beszel panel (free advert because it's also OSS, lightweight Go binary) henrygd/beszel

Beszel - Data Exporter Tool I hope this gets included in their software, and this can go away, but I wanted a way to document my servers and added a lookup IP to get location information. Exports the systems monitored by Beszel to a Markdown inventory table, followed by a fleet summary. It reads the PocketBase SQLite database directly in read-only mode, so the app does not need to be running and nothing is written to the database. Example output Here is a sample of what beszel-export -location produces, as GitHub renders it. The hosts are made up and the IPs come from the reserved documentation ranges. The real file also starts with a # Beszel Systems heading and a _Generated <date>_ line. |System|Hostname|Host / IP|Location|Port|OS|Kernel|Memory|CPU|Cores|Disks|Disk Used| |:-|:-|:-|:-|:-|:-|:-|:-|:-|:-|:-|:-| |backup-01|backup-01|192.0.2.10|Amsterdam, North Holland, Netherlands|45876|Debian GNU/Linux 12 (bookworm)|6.1.0-37-amd64|15.6 GB|Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz|4 (8 threads)|root 1.78 TB|42%| |db-primary|db1|198.51.100.20|Frankfurt am Main, Hesse, Germany|45876|Ubuntu 24.04.3 LTS|6.8.0-90-generic|7.8 GB|AMD EPYC 7313 16-Core Processor|4|root 159.8 GB|61%| |legacy-win|WIN-EXAMPLE01|203.0.113.30|Dallas, Texas, United States|45876|Windows Server 2019 Standard|—|—|Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz|2|—|38%| |old-agent|—|203.0.113.45|Toronto, Ontario, Canada|45876|Linux|—|—|—|—|—|27%| |web-01|web-01|192.0.2.50|New York, New York, United States|45876|Debian GNU/Linux 13 (trixie)|6.12.48+deb13-amd64|1.9 GB|AMD EPYC 7763 64-Core Processor|2|root 49.8 GB|23%| Summary |Metric|Best guess|Basis| |:-|:-|:-| |Systems|5|—| |Total RAM|~40.9 GB|25.3 GB reported by 3 systems + 2 unreported at median 7.8 GB| |Total disk space|~2.30 TB|1.98 TB reported by 3 systems + 2 unreported at median 159.8 GB| |Total CPU cores|~16 (20 threads)|12 reported by 4 systems + 1 unreported at median 4|

How to Monitor Your Homelab with Beszel and Dozzle Managing a homelab often starts with a single Docker container and quickly escalates into dozens of self-hosted services. As the footprint grows, keeping tabs on CPU spikes, memory leaks, disk wear, and container logs becomes essential. The traditional solution, which usually involves spinning up a heavy monitoring stack like Prometheus, Grafana, Node Exporter, and Loki, often consumes more resources than the homelab services themselves. For a modest server or a collection of low-power nodes, you need something that is fast, lightweight, and simple to configure. Beszel and Dozzle make a great alternative. Beszel provides real-time system metrics and container resource usage across multiple nodes. Dozzle complements it by offering a web-based, real-time log viewer for all running containers. Together, they form a monitoring setup that runs on less than 50MB of RAM. In this guide, we will walk through setting up a clean deployment of both tools on your server, and then show you how to run Beszel on an old Android phone to monitor its resource usage as an auxiliary homelab node. --- Beszel vs Dozzle: What's the Difference? While both tools monitor Docker environments, they solve two completely distinct operational needs: | Feature / Capability | Beszel (Metrics & Alerts) | Dozzle (Log Streaming) | | :--- | :--- | :--- | | Primary Purpose | System & Container Resource Metrics | Real-time Container Log Viewer | | What It Tracks | CPU, RAM, Disk I/O, Network, GPU, S.M.A.R.T, Docker Stats | stdout & stderr Docker Container Logs | | Architecture | Central Hub + Lightweight Agents across nodes | Single container connected to /var/run/docker.sock | | Historical Data | Yes (Stores long-term trend graphs) | No (Pure live stream, no database overhead) | | Alerting | Discord, Telegram, Pushover, Webhooks | None (focuses solely on log viewing) | | Memory Footprint | ~15MB – 25MB RAM | ~10MB – 20MB RAM | Summary: Use Beszel to find out which service is hogging memory or when your server is down. Use Dozzle to inspect why a container crashed by reading its live log output. --- Why Beszel and Dozzle? - Beszel is an open-source, lightweight resource monitor. It uses a hub-and-agent architecture. You host one central Hub (which displays the dashboard) and install a tiny Agent on each machine you want to monitor. It tracks CPU, memory, disk, network, GPU usage, temperatures, and per-container resource metrics. - Dozzle is a dedicated log viewer. It streams Docker container logs directly to your browser. It does not store logs or index them; it simply connects to the Docker socket to provide instant visibility when debugging. --- Why Beszel is a self-hosting must-have When self-hosting, your hardware resources are usually at a premium. Unlike enterprise setups with dedicated operations budgets, a home server might be an old optiplex, a Raspberry Pi, or a repurposed laptop. You need deep visibility, but you cannot afford to waste 1-2GB of RAM on Prometheus and Grafana. Beszel solves this problem by packing three critical monitoring components into an incredibly lightweight footprint. The main home dashboard lists all your systems side-by-side: !The main Beszel homepage shows all the devices currently being monitored. Beszel splits metrics into three specific categories: 1. System metrics Beszel tracks long-term system resource trends, including CPU, RAM, network bandwidth, and disk space usage. This lets you view historical spikes and spot pattern changes over days, weeks, or months. !View detailed system metrics such as CPU usage, memory utilization, and network traffic over time. 2. Container metrics Instead of running docker stats in a terminal to see which service is slowing down your system, Beszel auto-detects running containers and charts their individual resource footprint. If a container starts eating memory or pinning the CPU, you will see it immediately. !Beszel charts individual resource utilization profiles for all of your Docker containers. 3. S.M.A.R.T metrics Hard drive failures are one of the most common causes of data loss in a homelab. Beszel queries S.M.A.R.T database statistics to track temperature, write stats, bad sectors, and overall disk health. It can alert you before a drive completely dies. !Access storage health indicators like S.M.A.R.T data directly inside the dashboard to monitor disk wear. 4. Real-time alerts A monitoring tool is only as good as its notification engine. Beszel lets you configure threshold triggers for critical system metrics. You can set up rules to alert you if a system goes offline, CPU temperature rises too high, memory exceeds a safe range, or disk space runs low. It natively integrates with Discord, Telegram, Pushover, Gotify, and generic webhooks. !Configure granular notification thresholds for CPU, memory, and temperature metrics directly from the Hub. --- 1. Setting up Beszel Because Beszel splits visual presentation from metric gathering, we host the central dashboard (the Hub) and the collector (the Agent) on our primary server. Generic Docker Compose configuration Create a file named beszel-compose.yml. This configuration defines both the central hub and the agent that monitors the host server. services: beszel: image: henrygd/beszel:latest container_name: beszel restart: unless-stopped ports: - 9002:8090 volumes: - ./beszel_data:/beszel_data environment: PUID: 1000 PGID: 1000 TZ: UTC # Security: restricts embedding in frames CSP: "frame-ancestors 'self';" beszel-agent: image: henrygd/beszel-agent:latest container_name: beszel-agent restart: unless-stopped network_mode: host cap_add: - CAP_PERFMON - SYS_RAWIO - SYS_ADMIN # Expose host hardware and storage info devices: - "/dev/dri/card0:/dev/dri/card0" # your graphics card - "/dev/sda:/dev/sda" # your storage device - "/dev/nvme0:/dev/nvme0" # your storage device volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket:ro # Add optional path to monitor host storage mounts if needed # - /mnt/storage:/extra-filesystems/storage:ro environment: PORT: 4567 KEY: "YOUR_AGENT_PUBLIC_KEY_FROM_HUB" Explaining the configuration parameters 1. network_mode: host: The agent runs directly on the host network stack to reliably fetch system metrics and network statistics. 1. cap_add (Capabilities): Providing capabilities like SYS_RAWIO and CAP_PERFMON allows the agent to read hardware temperatures and drive health (SMART data) safely. 1. KEY: This is the public key generated by the Beszel Hub. When you first launch the Hub dashboard (at http://<your-server-ip>:9002), create an account, click "Add System", and copy the generated public key into your agent environment file or docker-compose definition. --- 2. Setting up Dozzle Dozzle runs as a single lightweight container. It only needs access to the read-only Docker socket to read logs from other containers running on the same host. Generic Docker Compose configuration Create a file named dozzle-compose.yml: services: dozzle: container_name: dozzle image: amir20/dozzle:latest restart: unless-stopped ports: - 8080:8080 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro environment: DOZZLE_NO_ANALYTICS: "true" # Optional: Enable actions (Start/Stop/Restart) directly in the UI # DOZZLE_ENABLE_ACTIONS: "true" # Optional: Enable basic username/password authentication # DOZZLE_AUTH_PROVIDER: "simple" Once running, navigate to http://<your-server-ip>:8080 to access the dashboard. Although Dozzle has recently added basic container statistics (like CPU and memory indicators on the home screen), its primary strength lies in its raw log streaming. Beszel is much better suited for system and container resource monitoring since it stores historical data. Keep Dozzle for viewing, filtering, and debugging your container logs in real time. !Dozzle lists all running containers alongside basic resource footprints on the main page. Selecting any container immediately opens a real-time, scrolling log output window, which makes troubleshooting and tracking down runtime exceptions simple. !Filter and search live log streams directly inside your browser window. --- 3. Repurposing an old Android device as a node One of the best ways to practice self-hosting sustainability is turning old Android phones into lightweight servers. You can run database backups, lightweight script runners, or DNS servers on them. Because Beszel is compile-friendly, you can run the static arm64 binary of the agent directly on your Android device to monitor its CPU temperature, battery percentage, RAM, and network usage. Setting up the agent via Termux To install the agent on Android, you will use Termux, a terminal emulator and Linux environment app. Step 1: Install Termux Install the latest version of Termux from F-Droid or GitHub. Avoid the outdated version on the Google Play Store. Step 2: Download the static ARM64 agent binary Open Termux on the Android device and update packages. Download the latest compiled static arm64 Linux binary directly from the Beszel GitHub Releases page: # Update package repositories pkg update && pkg upgrade -y # Download the static arm64 agent binary curl -s -L -o beszel-agent https://github.com/henrygd/beszel/releases/latest/download/beszel-agent-android # If you run into compatibility issues, you can download the standard static Linux arm64 binary: # curl -s -L -o beszel-agent https://github.com/henrygd/beszel/releases/latest/download/beszel-agent_Linux_arm64.tar.gz # Make it executable chmod +x beszel-agent Step 3: Run the agent To start the agent and hook it up to your server's central Hub, define the incoming port and the public key you generated inside the Hub dashboard: PORT=4567 KEY="YOUR_HUB_PUBLIC_KEY" ./beszel-agent > Root vs. Non-Root: Running as a standard user in Termux works for general CPU and memory stats. However, if your Android device is rooted and you want full disk and battery metrics, run the binary as superuser by prefixing the command with su (using Magisk/KernelSU). To keep the agent running in the background on Android, you can use tmux, nohup, or write a simple Termux service script using Termux-services. --- 4. Testing and verification Once you have set up the containers and Android agent: 1. Navigate to your central Beszel Hub at http://<server-ip>:9002. 1. Your primary server (where the agent runs with network_mode: host) should already show metrics. 1. Add a new system for the Android device. Input the phone's IP address and port 4567. 1. Within a few seconds, the phone's stats, including CPU spikes and memory consumption, will populate in the dashboard. --- Originally published at nkaushik.in

Running a NAS or home server? Beszel gives you a simple dashboard for CPU, RAM, disks, and Docker containers. Track historical metrics, set alerts, and check multiple machines from one place. henrygd/beszel #SelfHosted #Monitoring

Use Beszel to Monitor your VPS and Homelab Servers. Install main Dashboard on one of the VPS and a Light Agent on the rest of the servers. I was able to spot that one of the VPS' Storage is 71% full, will fix it soon. henrygd/beszel t.co

I needed monitoring and graphs for the few servers I run, so I installed Beszel and I couldn't be happier. Very easy to set up, not as heavy and AI infested as Grafana or Netdata, and looks clean. henrygd/beszel