Product guide

Self-hosted clients: setup, usage, and decision guide

Learn when self-hosted clients are the right tool, how to install them in minutes, and how to choose between server agents, self-hosted runners, and public monitor checkers.

Why use a self-hosted client

Monitor private endpoints not reachable from public internet.
Run checks from your own network boundary for network-path and compliance controls on where probes originate.
Measure service health from a specific office, VPC, or datacenter path.
Keep monitor logic in xUptime while controlling where checks are executed.

Self-hosted clients become monitor regions like SELFHOSTED-..., so assigning a region decides where checks run.

Note: monitor configuration and check results are still stored in the xUptime backend unless you self-host the full platform.

Set it up (first-time)

Open Dashboard → Monitors → Self-hosted clients.
Create a client name (one runner per host is recommended).
Copy the one-time API key and the generated one-line install command.
Run the install command on the target Linux host.
Return to the page and confirm the client appears in Configured clients and is online.

The installer creates the uptime-selfhosted-client.service service.

curl -fsSL "https://xuptimemonitor.com/api/self-hosted/install-go" | \
sudo env SELFHOSTED_BASE_URL="https://xuptimemonitor.com" SELFHOSTED_API_KEY="shc_..." bash

Use it in monitors

Create or edit a monitor.
In Regions, select your self-hosted region ID.
Optionally keep one or more public monitor checker regions for outside-in visibility.
Save and verify history entries show your self-hosted region as the check location.

A monitor can use both public checker regions and self-hosted regions at the same time (hybrid monitoring).

Operate it day to day

Use one client per runner host so revoking a key only impacts that host.
Rotate credentials by creating a new client, reassigning monitor regions, then deleting the old client.
Watch Last seen to catch runner outages early.
Review plan limits for max self-hosted clients and monitor-per-client caps.

When to use what

Option	Use when	Strengths	Not for
Public monitor checkers	You need internet-facing uptime checks from managed regions.	Zero infrastructure to run, easy regional redundancy.	Private-only endpoints behind VPN/firewall.
Self-hosted client	You need checks to originate inside your own network.	Private path validation, controlled probe origin, hybrid with public regions.	Host resource metrics and command automation.
Server agent	You need host telemetry and automated remediation commands.	CPU/memory/disk signals, heartbeat tracking, monitor-down automation target.	Replacing distributed endpoint checker regions by itself.

Practical default: keep at least one public checker for external visibility, add self-hosted regions for internal paths, and use server agents on critical hosts for infrastructure metrics and auto-commands.