Multi-server monitoring

Monitor daemon

phelix monitor starts the long-running gRPC monitoring daemon. It restores managed applications that were previously running (auto-start), opens a single long-lived TLS-secured gRPC stream to the Phelix backend while at least one app is watched (requires an authenticated session - see Authentication), monitors application status across all servers, sends application information, resource metrics, and logs of every watched app to the central server roughly every 2 seconds (see Per-app watching below), reconnects automatically with exponential backoff if the connection is lost, and provides real-time updates for all managed applications.

phelix monitor

Service lifecycle

The daemon runs in the foreground and stays attached to the terminal when invoked manually. On Linux it is normally supervised directly by the systemd unit created by the installer (/usr/local/bin/phelix monitor as ExecStart) - there is no backgrounding shell wrapper.

sudo systemctl start phelixsudo systemctl restart phelixsudo systemctl stop phelixsudo systemctl status phelixsudo journalctl -u phelix -f

Server fleet

Phelix can monitor multiple servers simultaneously. Each server running Phelix registers itself with the central monitoring service, sends regular status updates, maintains its own application state, and syncs with other servers when needed.

1. 1
   Register

   Each server authenticates and opens its TLS-secured gRPC stream while at least one app is watched.
2. 2
   Report

   Servers stream status, resource metrics, and logs of watched apps roughly every 2 seconds.
3. 3
   Synchronize

   The dashboard unifies updates while each server retains local application state.

Per-app watching

Each application has a watching state that decides whether that app participates in backend monitoring and reporting. It is a per-app opt-in with disabled as the default: new apps, and apps from installations that predate the feature, are never monitored remotely until you say so.

phelix watch api              # enable:  api's monitoring data goes to the backendphelix watch api --disable    # disable: no monitoring data for api

You can also declare the state in phelix.yaml:

watching: enable   # or disable; phelix init writes disable

When the key is present, phelix build and phelix rebuild apply its value to the app - the project file is the desired state, exactly like the health: block. A phelix.yaml without the key (older projects) leaves the app's current state untouched. phelix watch updates both runtime state and the watching: key in the project's existing phelix.yaml, so the next rebuild preserves your choice. Without a project configuration file, it changes only runtime state and creates no file.

The state persists in apps.json, is shown by phelix list (WATCHING column) and phelix status (Watching column), and takes effect on the monitor daemon's next reporting tick. No restart is needed.

When watching is enabled, the app participates in backend monitoring as usual: app metrics, health snapshots, app logs, deployment topology, and dashboard registration flow to phelix.anophel.com. When watching is disabled, none of that data is sent for the app. The backend receives no monitoring stream for it at all (not an empty payload). Everything else keeps working exactly as before: the app can still be built, run, stopped, restarted, rolled back, and inspected locally, local health checks and auto-restart keep running, and phelix list / phelix status show its full local state.

Dashboard-issued remote commands, including rollback, matrix, and webhook management, cannot reach a server while none of its apps are watched. Local commands continue working. One server can mix watched and unwatched apps freely.

This is useful for Free-plan users choosing which application/server combination to monitor remotely. The CLI remains free and local: this flag has no subscription checks; backend plan quotas are enforced server-side.

Requirements

• Go and/or Rust toolchain (auto-installed on Linux if missing)
• Internet connection for authentication and monitoring (only for the dashboard)
• Sufficient permissions to create and manage application files
• Network access between servers (if monitoring multiple servers)
• Docker (only if using phelix dockerize)