One Hostwatch service: workspace and server access

Central management: your workspace

The website handles registration, company workspaces, accounts, billing, team access and management across connected servers. The current iPhone and iPad app connects through this control plane, which may be hosted or supplied by your administrator.

You can set up your company and enroll compute before connecting a monitored server. Registration never attaches your company to the operator’s infrastructure.

Go component: operations on its own server

The installed Go service is part of Hostwatch. It provides host measurements, service and process inspection, HTTP evidence, cleanup and explicitly configured controls on the server where it runs. Available modules depend on the operating system and installed connectors.

The same operational areas can be presented in the app within this server scope. Company registration, platform administration, billing, account management and control of other servers belong to the central service. A separate local website is not required.

Today, the local terminal monitor and authenticated API/MCP can work without the website. The mobile app does not yet support a direct Go connection.

hostwatch-agent top -config /etc/hostwatch/agent.json -once

Planned: connect the app directly to one server

The intended app flow offers Workspace and Direct server as explicit connection modes. Direct server connects only to the selected installed Go service, without a website account or website availability. This mode is planned, not available in the current TestFlight build.

The server owner approves a separate device permission for that phone. A direct connection must not copy the server’s master credential into the app or turn a device permission into a company account. Access to other servers requires a separate authorized connection.

A direct profile should show the server identity, connection status and allowed operations. Only capabilities granted by that server appear; central account and billing screens stay in the workspace mode.

What autonomous operation means

If the website is unavailable but the app can reach its directly paired server, local monitoring and permitted controls should continue. That requires a reachable HTTPS or private-network route to the server. It does not mean controlling a server with no network connection.

If the server is unreachable, the app should keep the last successful readings with their timestamps and an offline label. New writes must fail clearly, without being queued for an unexpected later restart or cleanup. Switching modes must never silently reuse another profile’s credentials.

Server-to-server moves need separately authorized access to both endpoints and a durable migration coordinator. A single direct-server profile does not authorize fleet-wide migrations.

Mesh compute: an explicit resource permission

Monitoring a server and lending its CPU or memory are independent choices. Current compute participation uses the hetero-worker connector with a one-use join code from Devices & compute. The Go monitoring service alone does not start a model worker.

Choose a private network, resource share, working hours, job kinds and pause state. Community participation is a separate opt-in. Installing Go or pairing a phone never automatically shares resources.

1. Open Devices & compute in your workspace, even if there are no monitored servers.
2. Create a one-use join code for your private network.
3. Install and run the supported compute worker on your server.
4. Review its available resources and applied settings before using the network.