A Monitoring Tool That Stays Out of Your Way
Most server monitoring solutions come loaded with dashboards, agents, cloud dependencies, and pricing tiers that only make sense once your infrastructure has already scaled beyond the point where you needed help. Beszel takes the opposite approach – it is a single-binary, self-hosted monitoring tool built to give you real-time visibility into CPU, memory, disk, and network usage across multiple servers, without requiring a database engine, container orchestration, or a cloud account to get started. If you run a homelab, a VPS, or a small fleet of Linux machines and you want an honest picture of what those systems are doing, Beszel fits the job.
The architecture is worth understanding before you install anything. Beszel operates on a hub-and-agent model. You run one central hub – the web interface and data store – and deploy a lightweight agent binary on every server you want to monitor. The agent communicates back to the hub over SSH, which means no extra ports need to be opened on your monitored machines. That single design decision removes an entire category of security headaches that come with traditional monitoring setups.
What You Will Need Before You Start
To follow this guide, you need at least one Linux server to act as the Beszel hub. This can be a bare-metal machine, a VPS, or even a Raspberry Pi running a 64-bit OS. Docker and Docker Compose should already be installed on that hub machine, since the simplest deployment method uses a Compose file. If you prefer running Beszel as a native binary without Docker, the project provides pre-compiled binaries for Linux, and the process is nearly identical – just without the container layer. You will also need SSH access to any remote servers you plan to add as monitored agents.
Disk space requirements are minimal. Beszel uses an embedded database called PocketBase under the hood, which stores time-series metrics locally in a flat file. There are no PostgreSQL or MySQL dependencies. For a setup monitoring three to five servers with default data retention settings, expect the database to stay well under a gigabyte for months of historical data. That makes it practical to run on a small VPS with 512MB of RAM without meaningful performance impact.
Installing the Beszel Hub
Start by creating a directory for the deployment and writing a Docker Compose file. Create a folder called beszel in your preferred location, then open a new file named docker-compose.yml inside it. The Compose configuration for the hub is short – you are pulling the official henrygd/beszel image, mapping port 8090 on the host to port 8090 in the container, and mounting a local ./beszel_data directory as persistent storage for the embedded database.
Your Compose file should look like this: set the service name to beszel, use image henrygd/beszel:latest, set restart policy to unless-stopped, map ports as “8090:8090”, and mount the volume as ./beszel_data:/beszel_data. Once the file is saved, run docker compose up -d from that directory. Docker will pull the image and start the container in the background.
Open your browser and navigate to http://your-server-ip:8090. You will be greeted by a first-time setup screen asking you to create an admin account. Set a strong password here – this account has full access to your monitoring data and hub configuration. After logging in, you will see the Beszel dashboard, which starts empty because no agents have been connected yet.
If you plan to expose the hub to the internet rather than keeping it on a private network, put it behind a reverse proxy like Nginx or Caddy with HTTPS enabled before adding agents. Sending monitoring data over an unencrypted connection is a risk not worth taking, even for a homelab setup. The hub itself does not handle TLS termination natively, so the reverse proxy layer handles that responsibility.
Adding Your First Agent
In the Beszel dashboard, click Add System to register your first monitored server. You will be asked to enter the server’s hostname or IP address, an SSH port (default 22), and the SSH user the agent will authenticate as. Beszel generates a unique SSH public key for each hub installation. You can copy this key from the dashboard during the add-system flow and append it to the ~/.ssh/authorized_keys file on the remote machine so the hub can connect.
Next, install the agent binary on the machine you want to monitor. Beszel provides a one-line install script: curl -sL https://raw.githubusercontent.com/henrygd/beszel/main/supplemental/scripts/install-agent.sh -o install-agent.sh && bash install-agent.sh. The script detects your system architecture, downloads the correct binary, installs it as a systemd service, and starts it automatically. Once the agent is running and the hub can reach it via SSH, the server will appear as active in your dashboard within seconds.
For Docker-managed environments, Beszel also offers an agent Docker image. This can be useful if your monitored server already runs everything through containers and you want to keep the agent managed the same way. The agent container requires host networking mode to accurately report system-level CPU and memory metrics rather than container-scoped ones, so make sure to set network_mode: host in the agent Compose file. If you are already running Portainer to manage Docker containers visually, deploying the Beszel agent as a stack there is a clean way to keep it alongside your other services.
Reading the Dashboard and Setting Alerts
Once agents are connected, each system gets its own card on the main dashboard showing live readings for CPU usage, memory, disk, and network throughput. Clicking into any system opens a detailed view with historical graphs plotted over time. The default retention period keeps several weeks of data, and you can adjust this from the admin settings. The graphs are not interactive in the same way as Grafana panels, but they cover everything a practical monitoring setup needs without requiring a separate visualization layer.
Alerts in Beszel are configured per system from the individual system view. You can set thresholds for CPU, memory, and disk usage, and when a threshold is breached, Beszel sends a notification through whatever channel you configure in the hub settings. Supported notification providers include Slack, Discord webhooks, Telegram, email via SMTP, and several others through a generic webhook option. The alert system is intentional in its simplicity – you define a percentage threshold and a target, and that is the full configuration surface. There is no query language to learn and no alerting pipeline to maintain.
One detail that separates Beszel from heavier alternatives is what it does not ask you to maintain. There is no Prometheus scrape config, no InfluxDB retention policy, no Grafana dashboard JSON to import and keep updated. The entire stack lives in a single container with a single data directory. Backups are a file copy. Upgrades are a docker compose pull && docker compose up -d. For anyone who has spent time nursing a full observability stack through a version upgrade at 11pm, that simplicity carries real value.
