A Monitoring Tool That Stays Out of Your Way
Most server monitoring setups carry a tax: heavy resource usage, complex configuration files, or a cloud dependency that defeats the point of self-hosting in the first place. Beszel cuts through that pattern by offering a lightweight, single-binary monitoring solution with a clean web interface, multi-server support, and minimal overhead. It is designed for homelab users and small infrastructure operators who want visibility without running a secondary server just to watch the first one.
Beszel works on a hub-and-agent model. You deploy a central hub on one machine – this hosts the web UI and stores data – and lightweight agents on any servers you want to monitor. The agents report CPU, memory, disk, network, and container stats back to the hub over a secure SSH tunnel. No ports need to be opened on the agent machines, which makes the security posture cleaner than most alternatives.
What You Need Before You Start
Beszel runs on Linux. The hub can be deployed via a pre-built binary or through Docker Compose, which is the recommended path for most users because it handles restarts and isolation automatically. You will need Docker and Docker Compose installed on the machine designated as your hub. For agent machines, Docker is optional since the agent binary can run directly as a systemd service.
The hub machine should be accessible from any server you plan to monitor. If you are running everything on a local network, this is straightforward. If your agent machines are remote or on different networks, make sure SSH connectivity exists between the hub and each agent. Beszel does not require the hub to be publicly accessible – agents initiate outbound connections, so the traffic direction works in your favor.
You will also want a domain or local hostname pointed at the hub machine if you plan to access the UI regularly. Beszel’s web interface runs on port 8090 by default, and while you can access it directly via IP, putting it behind a reverse proxy like Caddy or NGINX gives you HTTPS with far less manual effort. Caddy in particular handles certificate provisioning automatically if you have a public domain, which saves a configuration step.
Deploying the Hub with Docker Compose
Create a directory for Beszel on your hub machine – something like /opt/beszel – and place a docker-compose.yml file inside it. The official Compose file pulls the henrygd/beszel image, maps port 8090 to the host, and mounts a local ./data directory for persistent storage. That directory will hold the SQLite database Beszel uses to store agent data and user accounts.
The full Compose configuration looks like this:
- Image: henrygd/beszel:latest
- Port mapping: 8090:8090
- Volume: ./data:/app/data
- Restart policy: unless-stopped
Run docker compose up -d from that directory. Beszel will pull the image and start the hub. Open a browser and navigate to http://your-server-ip:8090. On first load, you will be prompted to create an admin account. Set a strong password here – this account has full access to all monitored systems and alert configurations.
Adding Agents to Your Monitored Servers
Once you are logged into the Beszel UI, click “Add System” to register a new agent. The interface will generate a unique agent configuration string for that server, including a key that the agent uses to authenticate with the hub. Copy this key before proceeding – you will need it when you install the agent on the target machine.
On the server you want to monitor, download the Beszel agent binary from the GitHub releases page. Beszel provides binaries for x86_64 and ARM architectures, so it covers most homelab hardware including Raspberry Pi devices. Make the binary executable with chmod +x beszel-agent and move it somewhere in your PATH, such as /usr/local/bin/.
To run the agent persistently, create a systemd service file at /etc/systemd/system/beszel-agent.service. The service definition should reference the agent binary, pass the hub address and the authentication key as environment variables or flags, and set Restart=always so it recovers from any crashes. Enable and start the service with systemctl enable –now beszel-agent. Within a few seconds, the agent will appear as connected in the Beszel UI, and you will start seeing live metrics populate for that machine.
If you are already running Glances for real-time system monitoring, you will notice Beszel takes a different approach: rather than a per-machine terminal dashboard, it centralizes all server views into a single persistent interface. That architectural difference matters when you are managing more than two or three machines and want historical graphs rather than a live snapshot. Beszel stores rolling data over time, so you can look back at a CPU spike from three days ago without having set up any separate logging stack.
Container monitoring works without extra configuration if Docker is running on the agent machine. Beszel will automatically detect running containers and display per-container CPU and memory usage alongside host-level stats. This is where the tool earns its keep for homelab operators who run a stack of self-hosted services – instead of logging into each box and running docker stats, you have a persistent overview of everything. Alert configuration lives in the UI as well, and you can set thresholds for CPU, memory, disk, or network with notifications sent over standard webhook endpoints, which covers most popular messaging platforms. The alert logic is simple by design, and that simplicity is what keeps Beszel from growing into the kind of tool it was built to replace.
