What Beszel Actually Does
Most server monitoring tools arrive with a sprawling feature list, a complex agent architecture, and a setup process that turns a half-hour task into an afternoon project. Beszel is the opposite. It is a lightweight, open-source monitoring platform built around a single hub-and-spoke model: one central hub server collects data from remote agents installed on each machine you want to watch. The interface is clean, the binary footprint is small, and the whole system can run on hardware that would struggle with heavier alternatives.
What makes Beszel worth the setup time is its focus. You get CPU, memory, disk, and network metrics displayed in a readable dashboard, with alert thresholds you can configure per system. There are no proprietary data pipelines to configure, no cloud accounts to authorize, and no licensing tiers to navigate. Everything runs on your own infrastructure, which makes it a natural fit for homelab operators, small teams managing a handful of VPS instances, or anyone who wants visibility without handing telemetry data to a third party.
Prerequisites and System Requirements
Beszel has a low barrier to entry from a hardware standpoint. The hub component – the central server that receives and displays data – runs comfortably on a single-core machine with 512MB of RAM. In practice, most people deploy it on a dedicated VPS or a spare machine on their local network. The agent component, which runs on each monitored host, uses negligible resources because it only collects system metrics and sends them outbound to the hub. No inbound ports are required on agent machines, which simplifies firewall management considerably.
You will need Docker installed on the hub machine if you choose the container deployment path, which is the most straightforward option. Alternatively, Beszel distributes precompiled binaries for Linux that you can run directly as a systemd service. For this guide, the Docker Compose path is used throughout, as it handles the database and web interface together in a single configuration file. The agent installation on remote hosts uses a single binary and a minimal systemd unit, making it easy to replicate across many machines without a configuration management tool. Make sure port 8090 is accessible on your hub machine from your browser, and that the agent machines can reach the hub on port 8090 as well – that single port handles both the web interface and agent communication.
Installing the Beszel Hub
Start by creating a directory for the Beszel configuration on your hub machine. A path like /opt/beszel works well. Inside that directory, create a file named docker-compose.yml with the following contents:
services:
beszel:
image: henrygd/beszel
container_name: beszel
restart: unless-stopped
ports:
– “8090:8090”
volumes:
– ./beszel_data:/beszel_data
Run docker compose up -d from that directory. Docker will pull the image and start the container. Within a few seconds, the Beszel web interface will be available at http://your-server-ip:8090. The first time you visit, you will be prompted to create an admin account. Set a strong password here – this is the only authentication layer protecting your monitoring data. After logging in, the dashboard will be empty until you add agents.
If you want Beszel accessible over HTTPS – which is advisable if the hub is internet-facing – place a reverse proxy in front of it. Nginx Proxy Manager, Caddy, or a Traefik instance all work without any special Beszel configuration. The container only needs to receive proxied traffic on port 8090. If you are running this inside a private network and connecting via a zero-trust overlay like Netbird, you can skip the public exposure entirely and keep the hub strictly internal.
Adding Agent Machines
In the Beszel dashboard, click Add System. You will be asked for a display name, the IP address or hostname of the remote machine, and a port for the agent to listen on (the default is 45876). After saving the entry, Beszel generates a unique public key for that agent connection. Copy this key – you will need it during agent installation on the remote host.
On the remote machine, download the Beszel agent binary. The project’s GitHub releases page lists precompiled binaries for Linux on amd64 and arm64 architectures. Download the appropriate binary to a directory like /usr/local/bin/beszel-agent and mark it executable with chmod +x. Next, create a systemd service file at /etc/systemd/system/beszel-agent.service. The service file sets two environment variables: KEY, which holds the public key you copied from the dashboard, and PORT, which should match the port you set when adding the system in Beszel. A minimal service file looks like this:
[Unit]
Description=Beszel Agent
After=network.target
[Service]
Environment=”KEY=paste-your-key-here”
Environment=”PORT=45876″
ExecStart=/usr/local/bin/beszel-agent
Restart=on-failure
[Install]
WantedBy=multi-user.target
Run systemctl daemon-reload, then systemctl enable –now beszel-agent. Within a minute, the agent machine should appear as connected in the Beszel dashboard with live metrics populating the graphs. If the system shows as pending, confirm the hub’s IP and port 45876 are reachable from the agent machine, and verify the key was pasted without trailing whitespace. Repeat this process for each host you want to monitor.
Configuring Alerts and Storage
Beszel supports per-system alerts for CPU, memory, disk, and network thresholds. To configure one, open a connected system in the dashboard and navigate to its settings panel. You can define a threshold value – for example, trigger an alert when CPU usage exceeds 85% – and choose a notification method. Beszel supports several backends out of the box, including email via SMTP, Telegram, Gotify, and a generic webhook option for anything else.
The alert system is intentionally simple. There are no complex query languages or alert routing rules. If you want conditional logic beyond basic thresholds, the webhook output lets you pipe notifications into something like n8n or a custom script. For most use cases – knowing when a disk is filling up or a server is under sustained load – the built-in threshold alerts are enough without additional tooling.
Data retention is controlled by Beszel’s internal SQLite database stored in the volume you mapped during setup. By default, Beszel keeps short-interval data for recent periods and compresses older data into longer intervals automatically, so the database stays manageable without manual cleanup. If you want to back up your monitoring history, a simple daily copy of the beszel_data directory is sufficient. There is no built-in backup scheduler, so this is one area where a cron job or your existing backup workflow needs to cover the gap. The database file itself is small enough that incremental backups over rsync or restic add almost no overhead to your backup window.
