Why Self-Hosted Monitoring Belongs on Your Server Stack
Most server owners eventually hit the same wall: cloud monitoring tools either cost too much at scale, phone home with your infrastructure data, or both. Beszel cuts through that problem by giving you a lightweight, self-hosted monitoring hub that tracks CPU, RAM, disk, and network metrics across multiple systems from a single web interface. It runs on virtually any Linux machine, requires minimal configuration, and stores everything locally so your telemetry never leaves your network.
What makes Beszel worth setting up over heavier alternatives is the architecture. There are two moving parts – a central hub that collects and displays data, and small agents you deploy on every machine you want to watch. The agents communicate back to the hub over SSH, which means no open firewall ports on the monitored machines, no complicated VPN setup, and no additional authentication layer to manage. This guide walks through getting both running from scratch.
What You Need Before Starting
Beszel’s requirements are deliberately minimal. You need a Linux machine to act as the hub – a small VPS, a spare home server, or even a Raspberry Pi 4 will handle dozens of agents without breaking a sweat. Docker and Docker Compose need to be installed on that machine. For each system you want to monitor, you only need SSH access and the ability to run a single binary; no Docker required on the agent side.
You should also have a domain name or at least a static local IP pointing to your hub machine if you plan to access the dashboard from outside your home network. A reverse proxy like Caddy or Nginx Proxy Manager is worth setting up in front of Beszel if you want HTTPS – and you do want HTTPS if this is going anywhere near the public internet. If you already run a self-hosted unified home server dashboard, Beszel integrates naturally into that kind of setup as a monitoring backend.
Installing the Beszel Hub
Start by creating a working directory for Beszel on your hub machine. A clean path like /opt/beszel keeps things organized and easy to find later. Inside that directory, create a docker-compose.yml file with the following content:
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 pulls the image and starts the container. Within a few seconds, the hub is running and listening on port 8090. Open a browser and navigate to http://your-server-ip:8090. On first load, Beszel presents a simple account creation screen – fill in an email and password, and that becomes your admin account. There is no separate user management complexity at this stage.
Once logged in, the dashboard is mostly empty because no agents have checked in yet. Before adding any, go into the settings area and copy the SSH public key that Beszel generates automatically during startup. This key is what your hub uses to authenticate when it pulls metrics from agent machines. You will need it in the next step.
Deploying Agents and Connecting Systems
The agent is a single binary that runs as a background service on each machine you want to monitor. On the target machine, download the appropriate binary for your architecture. For a standard 64-bit Linux system, the command looks like this:
curl -L https://github.com/henrygd/beszel/releases/latest/download/beszel-agent_linux_amd64.tar.gz | tar xz sudo mv beszel-agent /usr/local/bin/
Next, add the hub’s SSH public key to the ~/.ssh/authorized_keys file on the target machine. This is the key you copied from the Beszel settings panel. Without this step, the hub cannot authenticate and the agent will never report data. Create the file if it does not exist, and make sure the permissions on the .ssh directory are set to 700 and the authorized_keys file to 600 – SSH is strict about this and will silently refuse connections if permissions are wrong.
Start the agent with the following command, replacing the port with whichever port you want it to listen on internally (45876 is the default):
PORT=45876 beszel-agent
To make the agent survive reboots, create a simple systemd service file at /etc/systemd/system/beszel-agent.service:
[Unit] Description=Beszel Agent After=network.target [Service] Environment="PORT=45876" ExecStart=/usr/local/bin/beszel-agent Restart=always [Install] WantedBy=multi-user.target
Run sudo systemctl enable –now beszel-agent to start it and set it to launch at boot. Back in the Beszel hub dashboard, click “Add System,” enter the target machine’s IP address or hostname, the SSH port (usually 22), and the agent port you set (45876). Beszel connects over SSH, reaches the agent, and within seconds the system appears in your dashboard with live metrics flowing.
Making the Setup Production-Ready
Running Beszel on plain HTTP over port 8090 is fine for a local lab, but anything exposed to the internet needs a reverse proxy and TLS. With Caddy, a minimal configuration handles both automatically. Add a site block pointing your domain to localhost:8090, and Caddy provisions a Let’s Encrypt certificate without any manual certificate management. Nginx Proxy Manager works equally well if you prefer a GUI-driven approach.
Alert configuration is where Beszel earns its keep in a real environment. Inside the dashboard, each monitored system has a set of thresholds you can configure for CPU, memory, disk usage, and connection status. When a threshold trips, Beszel can send notifications through a growing list of providers including Telegram, Discord, Slack, and generic webhooks. Setting disk alerts at 80% and a connection-lost alert on every agent takes about five minutes and saves you from the discovery that a drive silently filled up over a weekend.
One practical consideration: the hub stores all collected metrics in a SQLite database inside the volume you mounted at /opt/beszel/beszel_data. That directory should be included in your regular backup routine. If the hub machine goes down and you have not backed up that directory, you lose your metric history and have to rebuild the agent registry from scratch. The database stays small for typical setups – monitoring ten machines over several months produces a database measured in megabytes, not gigabytes.
Multi-user access is supported, so you can create read-only accounts for team members who need visibility without admin rights. This matters most in shared homelab environments or small organizations where a few people need to check server health but should not have the ability to remove agents or change alert settings. The permission model is not granular enough for enterprise use, but for small teams it works cleanly and without the overhead of a full RBAC system.
