Monitor Any Machine From a Browser With Glances
Glances is an open-source system monitoring tool written in Python that goes beyond a simple terminal dashboard. When you run it in web server mode, it exposes a live, browser-accessible interface showing CPU usage, memory, disk I/O, network traffic, running processes, and more – no SSH session required, no client software to install on the machine you are watching from.
Installing and Configuring Glances
The fastest way to get Glances running is through pip, Python’s package installer. On a Debian or Ubuntu-based system, start by making sure Python 3 and pip are available: run sudo apt update && sudo apt install python3-pip -y. Once pip is ready, install Glances along with its optional web dependencies by running pip3 install glances[web]. The [web] extra pulls in Bottle and Waitress, which are the lightweight components that serve the web interface.
If you prefer containers, the official Docker image makes deployment straightforward. Pull and run it with docker run -d –restart=”always” -p 61208:61208 -p 61209:61209 -e GLANCES_OPT=”-w” –pid host nicolargo/glances. The –pid host flag is important – without it, Glances can only see processes running inside its own container rather than the full host process table. Port 61208 is where the web UI lives; 61209 is used for the API.
For non-Docker installs, starting the web server is a single command: glances -w. By default it binds to all network interfaces on port 61208. You can restrict it to a specific address with the –bind flag, for example glances -w –bind 192.168.1.50, which is worth doing if the machine has multiple interfaces and you only want monitoring traffic on your LAN. You can also change the port with –port if 61208 conflicts with something already running.
Glances reads its configuration from ~/.config/glances/glances.conf on Linux and macOS. If that file does not exist, you can generate a starting point by running glances –export-conf. The config file lets you set alert thresholds – for instance, defining at what CPU or memory percentage the interface should highlight a value in yellow or red. You can also use it to hide specific plugins, adjust refresh intervals, and configure Docker or GPU monitoring if those plugins are relevant to your setup.
Securing the Web Interface and Running It as a Service
By default, the Glances web UI requires no authentication. Anyone who can reach port 61208 on that machine can see every process, every open connection, and all system stats. That is acceptable on a fully isolated home lab network, but on anything with broader access you should enable the built-in password protection. Set it with glances -w –password and Glances will prompt you to create a username and password, storing the hashed credentials in its config file. The next time someone hits the URL, a browser login prompt appears before the dashboard loads.
For a stronger security posture, consider putting Glances behind a reverse proxy like Nginx. This lets you front the monitoring UI with a valid TLS certificate, use your own domain or subdomain, and apply access controls at the proxy level. A basic Nginx proxy block points proxy_pass at http://127.0.0.1:61208, with proxy_http_version 1.1 and the appropriate Upgrade and Connection headers set to support the WebSocket connection Glances uses for live updates. Once Nginx handles HTTPS termination, you can also disable the Glances password if you are relying on Nginx’s own auth_basic or an SSO layer instead.
Running Glances as a systemd service means it starts automatically at boot and restarts after crashes without any manual intervention. Create a new unit file at /etc/systemd/system/glances.service. The [Service] section should set ExecStart to the full path of the Glances binary followed by -w, set Restart=on-failure, and optionally set User to a dedicated low-privilege account rather than root. After saving the file, run sudo systemctl daemon-reload, then sudo systemctl enable –now glances to activate it immediately and register it for future boots.
If you are monitoring multiple machines, you do not need to open a separate browser tab for each one. Glances supports a client-server mode where one instance can pull data from remote agents. On each remote machine, start Glances as an XML-RPC server with glances -s. On the machine where you want to aggregate the view, connect to any of them using glances -c REMOTE_IP in the terminal. This is separate from the web UI mode – it is a terminal-based multi-host view – but it pairs well with a monitoring setup where you check individual host dashboards in the browser and use the CLI client for quick cross-machine comparisons.
Glances also exposes a REST API at /api/3/ on the same port as the web UI. Every metric visible in the browser is also available as JSON over HTTP. This makes it straightforward to pull data into external tools: a simple cron job or a small Python script can poll /api/3/cpu or /api/3/mem at regular intervals and write the results to InfluxDB or any time-series database. From there, a Grafana dashboard can visualize weeks of historical load data – something the live Glances interface, which only shows the current moment, cannot do on its own. For anyone already running a self-hosted stack that includes tools like Vaultwarden or similar services, adding Glances monitoring to each container host gives visibility into resource consumption across the whole environment.
Accessing the Dashboard and Reading the Data
Once Glances is running, open a browser and navigate to http://YOUR_SERVER_IP:61208. The interface loads as a single-page app that refreshes every few seconds. The top row shows CPU, memory, swap, and load averages at a glance, color-coded against the thresholds you set in the config file. Scrolling down surfaces per-process detail: each row shows PID, username, CPU percentage, memory usage, and the full command string – enough to identify a runaway process without needing to SSH in and run top. Network and disk panels show current read/write speeds and cumulative transfer totals since Glances started.
One detail worth knowing: the web interface does not auto-scale well on very small screens, so mobile use is workable but not ideal for reading the process table. The refresh interval defaults to three seconds, which keeps the page active enough to catch spikes but light enough that it does not become a source of load on the machine it is watching. You can raise that interval in the config file if the server is under-resourced – setting it to ten or fifteen seconds on a Raspberry Pi running several services keeps Glances itself from competing meaningfully for CPU time.
