What Beszel Is and Why It Belongs on Your Home Server
Server monitoring tools tend to fall into two camps: bloated enterprise platforms that require a team to configure, and minimalist scripts that barely surface useful data. Beszel sits outside both categories. It is a lightweight, self-hosted monitoring dashboard built around simplicity – one binary, one config file, and a clean web interface that shows CPU, memory, disk, and network stats across multiple systems in real time. It is designed for people who want visibility into their infrastructure without spinning up a full observability stack.
The appeal is straightforward. Beszel runs as a hub-and-agent architecture where a central hub collects data from lightweight agents installed on each machine you want to monitor. The hub serves the web UI, stores historical data in SQLite, and handles user authentication. The agent binary is tiny, requires no runtime dependencies, and communicates back to the hub over SSH tunnels – which means no exposed ports on the agent side. For anyone running a home lab or a small fleet of VPS instances, that design is a genuine advantage over tools that require open firewall rules or complex service meshes.
Prerequisites and System Requirements
Before installing anything, confirm your environment. The hub server needs a Linux machine with at least 512MB of RAM and enough disk space to hold SQLite history – a few gigabytes is more than sufficient for most setups. Beszel publishes pre-built binaries for amd64, arm64, and armv7, so it runs on standard VPS instances, Raspberry Pi hardware, and most home server configurations. Docker is not required but is fully supported if you prefer container deployments. Each agent machine needs SSH access from the hub, so plan your network topology accordingly before you begin.
You will also need a domain or local hostname pointed at your hub if you want HTTPS, which is worth setting up even for internal deployments. Beszel does not handle TLS termination natively, so a reverse proxy like Caddy or Nginx sits in front of it. If you already have a reverse proxy running for other self-hosted services, adding Beszel is a matter of a few additional config lines.
Installing the Beszel Hub
The fastest path to a working hub is the official install script. On your hub server, run the following command as root or a user with sudo access:
curl -sL https://raw.githubusercontent.com/henrygd/beszel/main/supplemental/scripts/install-hub.sh -o install-hub.sh && bash install-hub.sh
The script downloads the correct binary for your architecture, places it in /opt/beszel/, and creates a systemd service unit so the hub starts automatically on boot. Once the script completes, enable and start the service with systemctl enable –now beszel-hub. By default, the hub binds to port 8090. Navigate to http://your-server-ip:8090 in a browser and you will land on the initial setup screen where you create your admin account. That account is stored locally – Beszel does not phone home or require external authentication services.
After logging in, the dashboard is intentionally sparse because you have not connected any agents yet. Before doing that, configure your reverse proxy. For Caddy, a minimal configuration block looks like this: add your domain to the Caddyfile with reverse_proxy localhost:8090, then reload Caddy. For Nginx, proxy_pass to http://127.0.0.1:8090 and include the standard WebSocket upgrade headers – Beszel uses WebSockets for real-time data push, and without those headers the live graphs will not update. Once the proxy is running and your domain resolves, switch to the HTTPS URL for all further configuration.
User management lives under the Settings panel in the admin interface. Beszel supports multiple user accounts with read-only or admin roles, which is useful if you want to share dashboard access with other household members or colleagues without giving everyone the ability to add or remove systems. Create additional accounts now if needed, before you start adding agents – it keeps the setup process cleaner.
One configuration option worth setting early is the data retention period. Beszel defaults to storing 60 days of metrics history. For a home server with a modest SSD, that is fine. For a machine with limited storage – a Raspberry Pi running from a small SD card, for example – dropping that to 30 days reduces write wear and keeps the SQLite database small. The retention setting is under System in the admin panel and takes effect immediately without a restart.
Connecting Agents to the Hub
Each machine you want to monitor runs the Beszel agent binary. The agent does not expose any network ports of its own – it establishes an outbound SSH tunnel to the hub, which then uses that tunnel to pull metrics on a configurable interval. This means your monitored machines do not need to be publicly reachable, which is a practical benefit for home lab nodes sitting behind NAT or on private subnets.
To add a system, click Add System in the hub dashboard. Give it a name and enter the SSH connection details – host, port, and the user the agent will run as. The hub will display a public key that needs to be added to the authorized_keys file on the target machine for the specified user. Copy that key, paste it into ~/.ssh/authorized_keys on the agent machine, and ensure the permissions on that file are set to 600. Then, on the agent machine, run the agent 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 installs the agent binary and creates a second systemd service. Start it with systemctl enable –now beszel-agent. Within a few seconds of starting the agent, the hub dashboard will show the new system with live CPU, memory, disk, and network data. If the connection does not establish, the most common causes are a missing authorized_keys entry, a firewall blocking the SSH port on the agent, or SELinux policies on RHEL-based systems preventing the SSH tunnel. Check journalctl -u beszel-agent on the agent machine for specific error messages – the logs are readable and usually point directly at the problem.
Repeat this process for every machine you want to monitor. There is no practical limit on the number of agents a single hub can handle for home lab scale – the SQLite backend and the low-overhead agent design keep resource consumption minimal even with a dozen or more connected systems. Each system appears as a card on the main dashboard with a sparkline history chart, and clicking any card opens a full detail view with longer time-range graphs for each metric. Alert thresholds are configured per-system and can send notifications via email, Slack webhooks, Gotify, or any service that accepts generic HTTP POST webhooks.
Disk monitoring deserves a specific note. By default, the agent monitors the root filesystem. If your server has additional mount points – a large storage drive mounted at /mnt/data, a network share, a secondary SSD – those do not appear automatically. Add them by editing the agent’s environment file, typically located at /etc/beszel-agent.env, and setting the EXTRA_FILESYSTEMS variable to a comma-separated list of mount paths. Restart the agent service after editing, and those filesystems will appear as separate disk panels in the hub within the next polling interval. For anyone monitoring a NAS or a machine with tiered storage, this step is easy to miss but changes how useful the disk data actually is.
