ServerStatus-Rust Setup with a Localtonet HTTP Tunnel

How ServerStatus-Rust and Localtonet fit together

ServerStatus-Rust is a self-hosted monitoring system written in Rust. Its server receives reports from monitored machines and presents their status through a web interface. The project supports Linux, macOS, Windows, Android, and Raspberry Pi in its wider server and client ecosystem, although the one-touch installation documented in this guide is specifically identified for x86_64 CentOS, Debian, and Ubuntu.

The default configuration shown by the project listens for HTTP traffic on port 8080 and gRPC traffic on port 9394. The HTTP side serves the dashboard and supports HTTP client reporting. The documented local dashboard address is http://127.0.0.1:8080/, while the HTTP reporting route is http://127.0.0.1:8080/report. The project also supports gRPC reporting, but that is a distinct raw service and is not carried by the HTTP tunnel described here.

We deliberately split deployment into two phases. First, install and validate ServerStatus-Rust entirely on the host. Second, expose the already-working HTTP service with Localtonet. This order makes failures easier to diagnose because a blank dashboard or rejected report can be isolated from tunnel configuration.

Prerequisites and deployment choices

The documented one-touch experience applies to x86_64 CentOS, Debian, and Ubuntu. Run it from an account with permission to create /opt/ServerStatus, install required packages, create services, and manage the resulting processes. The example uses wget, bash, and unzip. Debian and Ubuntu systems use apt for the package example, while CentOS uses yum.

You also need at least one machine for the status server and, if you want real monitoring data, one or more machines on which to install the client. A client needs network reachability to the server endpoint selected for reporting. Test with one client before rolling the configuration out broadly.

Prepare unique client credentials in advance. In the project configuration, each entry in hosts has a unique name and a corresponding password. The name cannot be duplicated. Do not use the demonstration values from project examples on an internet-reachable deployment.

Choose an installation method

Install the ServerStatus-Rust server

The quickest documented server path creates /opt/ServerStatus, installs unzip, downloads the upstream one-touch script, and runs it. Package installation and system service creation may require a root shell or an appropriate privilege elevation method. Do not add sudo mechanically if your environment handles administration differently.

mkdir -p /opt/ServerStatus
cd /opt/ServerStatus

apt install -y unzip

yum install -y unzip

wget -O one-touch.sh 'https://raw.githubusercontent.com/zdz/ServerStatus-Rust/master/scripts/one-touch.sh'

bash -ex one-touch.sh

Alternative service-management script

The upstream status.sh script offers separate installation and management operations. Download and inspect it using the same precautions:

wget -O status.sh 'https://raw.githubusercontent.com/zdz/ServerStatus-Rust/master/scripts/status.sh'

After review, install only the server with:

bash status.sh -i -s

This script also documents commands for upgrading, uninstalling, reconfiguring, controlling, backing up, and restoring server and client installations. These become useful after initial deployment, and the relevant commands are covered in the operations section.

Manual execution and configuration testing

If you already have the project binaries and configuration in the current directory, the documented manual server command is:

./stat_server -c config.toml

Before starting it, test the configuration syntax:

./stat_server -c config.toml -t

For diagnostic logging, the project documents:

RUST_BACKTRACE=1 RUST_LOG=trace ./stat_server -c config.toml

Trace output can contain operational information. Capture and share it carefully, and redact credentials or private host information before including it in a support request.

Docker Compose alternative

The repository provides docker-compose.yml and config.toml files for container deployment. The documented downloads are:

wget -O docker-compose.yml 'https://raw.githubusercontent.com/zdz/ServerStatus-Rust/master/docker-compose.yml'
wget -O config.toml 'https://raw.githubusercontent.com/zdz/ServerStatus-Rust/master/config.toml'

Review both files before starting anything. In particular, verify the selected image, published ports, mounted paths, restart behavior, and all credentials in config.toml. The supplied evidence does not establish one universally correct Docker Compose startup command across Compose versions and environments, so this guide does not invent one. Use the command supported by your installed Docker Compose version after validating the current repository files.

Configure the server and monitoring identities

ServerStatus-Rust reads its server settings from config.toml. The project's example sets the gRPC listener to 0.0.0.0:9394 and the HTTP listener to 0.0.0.0:8080. A wildcard address accepts connections through every relevant interface unless the operating-system firewall restricts them.

grpc_addr = "0.0.0.0:9394"
http_addr = "0.0.0.0:8080"
offline_threshold = 30

The documented default offline threshold is 30 seconds. A host that does not report within that window can be treated as offline. Before changing it, consider the reporting interval, network stability, and how quickly you need an interruption to appear on the dashboard.

Static host entries

The hosts configuration mode creates an individual identity for each monitored machine. Each name must be unique. The password authenticates reports for that identity, while alias controls the display label. The project also documents fields such as location, type, notify, monthstart, disabled, and semicolon-separated labels.

The following structure uses placeholders intentionally. Replace them with unique, strong credentials and meaningful values:

hosts = [
  {
    name = "unique-host-id",
    password = "replace-with-a-strong-unique-secret",
    alias = "Application Server",
    location = "us",
    type = "kvm",
    notify = true,
    disabled = false
  }
]

Do not commit real host passwords to a public repository or paste them into logs, tickets, screenshots, or shell history. Restrict read access to the configuration file because it contains credentials accepted by the reporting service.

Dynamic registration groups

As an alternative to defining every host separately, ServerStatus-Rust supports hosts_group. Each group has a unique gid and password. Groups can organize hosts by location or purpose and can set common properties such as notification behavior. The documented group garbage-collection interval defaults to 30 seconds through group_gc = 30.

hosts_group = [
  {
    gid = "replace-with-a-unique-group-id",
    password = "replace-with-a-strong-group-secret",
    location = "us",
    type = "kvm",
    notify = true
  }
]

group_gc = 30

Choose either the individual hosts model or the hosts_group model for a given deployment design. A shared group secret is operationally convenient, but its security scope is wider than a unique secret per host. If a shared secret is exposed, rotate it and reassess every client using that group.

Administrator and notification settings

The configuration includes admin_user and admin_pass for administrative views such as /detail and /map. The project states that random values are generated when these are not set. Record generated credentials securely if your deployment relies on them, or set your own strong values according to your secret-management policy.

ServerStatus-Rust can send online, offline, and custom-rule notifications through mechanisms including Telegram, WeChat, email, and webhooks. Notifications are optional. The documented notification interval is 30 seconds, and the project provides a test operation:

./stat_server -c config.toml --notify-test

Notification templates can reference host data. Treat endpoint URLs, bot tokens, chat identifiers, email credentials, and webhook secrets as sensitive. Test with a controlled destination before enabling notifications for production systems.

Verify the local deployment before exposing it

A successful installer is not sufficient proof that the application is usable. Confirm the process state, configuration validity, listener, dashboard, and reporting behavior while everything is still local.

bash status.sh -s status

./stat_server -c config.toml -t

If the dashboard works through 127.0.0.1 but not through the server's LAN address, inspect http_addr and host firewall policy. If neither address works, focus on process state, configuration errors, port conflicts, and logs before creating a tunnel. If the dashboard works but the client remains offline, investigate client credentials, protocol selection, endpoint construction, and network reachability.

Install and connect monitoring clients

The management script supports a client-only installation. After downloading and reviewing status.sh on the monitored machine, install the client interactively with:

bash status.sh -i -c

The script also accepts a complete connection string. The documented format is:

protocol://username:password@master:port

For a local HTTP server, the upstream example is:

bash status.sh -i -c http://h1:p1@127.0.0.1:8080

Here, h1 corresponds to a configured host name and p1 to its password. Those are demonstration values only. A client on another machine cannot use 127.0.0.1 to reach your server because loopback always refers to the client machine itself. Replace the master address with an endpoint that resolves and routes to the actual ServerStatus-Rust server.

The project also documents a gRPC form:

bash status.sh -i -c grpc://h1:p1@127.0.0.1:9394

Choose the protocol intentionally. For this Localtonet workflow, HTTP is the relevant choice. Do not point a gRPC client at the public URL of an HTTP tunnel and expect protocol conversion.

Manage the client after installation

The service script provides direct client controls:

bash status.sh -c status
bash status.sh -c start
bash status.sh -c stop
bash status.sh -c restart

To change the client configuration, use the documented reconfiguration operation:

bash status.sh -rc

A complete connection string can also be supplied to the reconfiguration operation, but avoid placing a real password in reusable documentation or support messages. After any change, restart the client if required by the script's workflow, then verify that the intended host becomes online on the dashboard.

Expose the HTTP service with a Localtonet tunnel

Once http://127.0.0.1:8080/ works and at least one client reports successfully, Localtonet can provide remote access to the HTTP service. Our client establishes an outbound connection to a relay, so this workflow does not require inbound router port forwarding, a public IP address, firewall changes, or VPN setup.

The Localtonet client must run on the ServerStatus-Rust machine or on another device that can reach its port 8080. If both processes run on the same machine, use 127.0.0.1 as the local target. If they run on different machines, use a private address reachable from the Localtonet client and restrict that network path appropriately.

For the current dashboard sequence and field names, consult our Localtonet HTTP tunnel documentation. The public tunnel remains available only while the selected Localtonet client is connected and the tunnel is running.

Secure the monitoring service before wider use

A monitoring dashboard can reveal host names, operating systems, capacity, utilization, locations, labels, and availability patterns. That information can be operationally sensitive even when the page does not provide direct server control. Publishing it should therefore be an explicit decision, not an accidental side effect of installation.

The public Localtonet HTTP address uses HTTPS at the tunnel edge. That protects the public browser connection to the edge, but it does not remove the need for application authorization, secure credential handling, least privilege, and a protected local path between the Localtonet client and ServerStatus-Rust.

If the Localtonet client and monitoring server are on different devices, traffic between them follows your local network path. Evaluate that segment according to your threat model. Do not assume that a public HTTPS URL automatically changes or secures every internal hop.

Routine operation, upgrades, backups, and troubleshooting

Service controls

The management script provides the following documented server operations:

bash status.sh -s status
bash status.sh -s start
bash status.sh -s stop
bash status.sh -s restart

Use the corresponding client operations with -c. When changing config.toml, validate it before restarting whenever the binary-based test is available. A configuration typo can prevent the process from returning after a restart.

Upgrades

The script supports separate and combined upgrades:

bash status.sh -up -s
bash status.sh -up -c
bash status.sh -up -a

The first upgrades the server, the second upgrades the client, and the third upgrades both. Before an upgrade, read the release notes for configuration changes, back up the current deployment, and plan a rollback. Do not assume that every historical configuration remains compatible with every release.

Backup and restore

The documented backup operations are:

bash status.sh -b -s
bash status.sh -b -c
bash status.sh -b -a

Restore operations use:

bash status.sh -rs -s
bash status.sh -rs -c
bash status.sh -rs -a

A backup is useful only if it can be restored. Periodically test restoration in an isolated environment, verify that credentials and configuration are present, and keep backup files protected because they may contain monitoring and notification secrets.

Uninstallation

When a server or client is no longer needed, the management script documents:

bash status.sh -un -s
bash status.sh -un -c
bash status.sh -un -a

Stop and delete the corresponding Localtonet tunnel separately. Removing ServerStatus-Rust does not automatically remove a tunnel configuration, and deleting a tunnel does not uninstall the local monitoring application.

Troubleshooting reference

A practical diagnostic sequence

Work from the inside out. First confirm the ServerStatus-Rust process is running. Then verify http://127.0.0.1:8080/. If the Localtonet client runs elsewhere, verify the server's private port from that device. Next confirm that the Localtonet device is connected and the tunnel is running. Finally, test the assigned public URL.

For client-reporting issues, separate protocol problems from authentication problems. Confirm that an HTTP client is pointed at the HTTP service and that its host name and password correspond exactly to the server configuration. A dashboard that loads correctly proves basic HTTP reachability, but not reporting authorization.

Avoid changing the application, firewall, DNS, client credentials, and tunnel simultaneously. Make one controlled change, test it, and record the result. This approach is slower than random edits for the first minute but substantially faster when diagnosing a multi-layer deployment.

Frequently asked questions