Getting Started

• Introduction
• Requirements
• Register & Install the Agent
• HAProxy Server Pools
• Overview & concepts
• Create your first pool & Enroll your first member
• Pool workspace (Overview, Settings, DNS, DR, Monitoring)
• Pool members & enrollment
• DNS failover & traffic cutover
• HAProxy operations
• Backups & disaster recovery
• Recipes & scheduled jobs
• Agent reference
• Troubleshooting & FAQ
• Linux Server Pools
• Part 1 - Overview & Concepts
• Part 2 - Member workspace (per-server tabs)

Introduction

A message from the developers.

ServersCTL started life as a solution to a problem many of us face: HAProxy is often the single point of failure in an otherwise resilient infrastructure.

The original goal was simple. Build a way to monitor HAProxy instances and automatically move traffic if a load balancer becomes unavailable without VRRP or a floating/failover IP address. Once the first working version was in place, it became clear that the underlying concept was far more powerful than we had anticipated.

By combining a lightweight agent with infrastructure-focused automation, we found ourselves solving many of the day-to-day challenges that infrastructure managers encounter. Monitoring, backups, disaster recovery, DNS failover, cPanel replication, service management, and operational visibility could all be brought together into a single platform.

ServersCTL is not intended to replace the tools you already use. Instead, it aims to sit alongside them, providing practical automation and visibility where it matters most.

Today, we are releasing the Linux agent free of charge for anyone to use. Our hope is that it saves you time, reduces operational headaches, helps keep your services online, and perhaps one day saves your bacon when you need a backup or a failover plan.

We release this with no limits on the number of pools you can have or the number of servers you may manage. If you find this product useful, support us by upgrading your account, contributing ideas or even reporting a bug. Everything helps.

We hope you find it useful.

What the agent is

The ServerCTL/BalCTL agent is a small Python 3.9+ process (stdlib only, no pip packages) that runs on each pool member Linux VM. It:

1. Heartbeats to the control plane over outbound HTTPS (proves liveness, reports host/HAProxy state).
2. Pulls jobs from the control plane after each successful heartbeat (install, reload, backup, restore, firewall, etc.).
3. Optionally self-updates from a published zip bundle.

It is deployed as a systemd service: balctl-heartbeat.service, with secrets in /etc/balctl/agent.env.

Current release: check AGENT_VERSION in agents/balctl_heartbeat.py or python3 balctl_heartbeat.py --version.

Requirements

Server Stack

Operating system

• Supported: Debian/Ubuntu and RHEL family (AlmaLinux, Rocky, CentOS).
• Init: systemd (required — agent is designed as a systemd unit).
• Architecture: Linux x86_64 (typical VPS; agent uses standard distro package managers).

Runtime dependencies

Optional packages (installed by agent jobs when needed)

Network requirements

Outbound HTTPS (required)

The VM must reach:

All agent API traffic must use HTTPS — the agent refuses plaintext BALCTL_API_BASE / BALCTL_UPDATE_URL (v28+).

Inbound (not required)

Panel-driven operations use the outbound job queue. No inbound SSH or agent port is required if the agent runs as root for privileged jobs.

IP allowlisting (enrollment)

When you create a pool member, you must supply at least one allowed source IPv4. This is the VM’s outbound/egress IP as seen when it calls the control plane — not necessarily its SSH IP or the IP traffic should hit.

The control plane validates CF-Connecting-IP against the enrolled allowlist on every agent request. Mismatch → 403.

Enrollment requirements

Before the agent can heartbeat, create the member in the dashboard (Add pool member):

Authentication model

Register & Install the Agent

Installation

When adding a pool, you will be asked whether the pool will be for HAProxy nodes. 

Only select the HAProxy Pool Template if the backend server(s) are currently running, or will be running, HAProxy.

For all other server types—including cPanel, OpenLiteSpeed, MySql/MariaDB, and general-purpose Linux hosts—select Generic Linux.

Choosing the correct template ensures that the UI enables the appropriate features and management tools for that server type. If you accidentally select the wrong template, remove any members from the pool and recreate the pool on the correct template.

Recommended: one-shot from the dashboard

You can access the UI using https://serversctl.com/app or https://balctl.com/app. Only the public websites are different.

1. Register an account at https://serversctl.com/app/
2. Add a new pool. https://serversctl.com/app/sites
   • Servers can be pooled together. For example, cPanel Servers, LiteSpeed, MariaDB/MySQL all use the Generic Linux template, or HAProxy servers use the dedicated HAProxy template.
3. Select Add Member. The modal generates a paste-ready command that:
   • Ensures unzip + python3 (via apt or dnf/yum).
   • Downloads https://download.serversctl.com/agent.zip.
   • Runs balctl-agent.sh --enrol --key … --hostname … --api-base ….
   • Writes /etc/balctl/agent.env, runs --update, enables systemd.
4. The ServersCTL UI will now start to report agent information.
   • See troubleshooting if you have problems.

To add further members to a pool. Keep using the Add Member button.

Files after install

Bundle contents (agent.zip)

Flat zip: balctl_heartbeat.py, balctl-agent.sh, balctl-heartbeat.env.example, balctl-heartbeat.service, README.md, LICENSE, INSTALL_VM.txt.

---

Configuration (/etc/balctl/agent.env)

If your configured hostname is different from the hostname sent to ServersCTL, use BALCTL_HOSTNAME

Systemd loads this via EnvironmentFile=/etc/balctl/agent.env. Manual sudo python3 … runs merge missing vars from the same file.

HAProxy Server Pools

Overview & concepts

What is an HAProxy pool?

An HAProxy pool is a ServerCTL deployment preset for the edge tier: public DNS, one or more enrolled Linux VMs running HAProxy, and optional automatic promotion when the active host fails.

ServerCTL is the control plane. It does not terminate customer traffic itself. It:

• Enrols VMs via the ServersCTL agent
• Publishes a managed A record through Cloudflare or cPanel/WHM
• Tracks heartbeats (~1s check-ins) and systemd HAProxy health
• Queues remote jobs (install, reload, backup, drain) that run on the next heartbeat

Status: HAProxy pools are well tested and in public beta.

Core terminology

Architecture (high level)

Health for failover: A member is unhealthy when:

1. No heartbeat within the failover delay window (10–120 seconds), or
2. HAProxy is monitored, and systemd reports HAProxy inactive

Important: Clients must use the failover hostname, not a member’s raw IP. ServerCTL moves the A record; your apps keep the same DNS name.

What HAProxy pools include vs other presets

HAProxy pools uniquely enable:

• Remote HAProxy jobs (install, reload, backup)
• HAProxy systemd probe on member cards
• Disaster Recovery tab (cross-member restore, 2+ members)
• Traffic-flow diagram on Overview
• HAProxy Status tab

Generic Linux pools hide HAProxy-specific jobs unless the agent detects HAProxy on the host.

Create your first pool & Enroll your first member

Create your first pool

Step 1 — Add pool

1. Go to Pools → Add pool
2. Choose the HAProxy template
3. Name the pool (e.g. production-edge)
4. After create, you land in the pool with a setup banner

Step 2 — Connect DNS (Settings)

ServerCTL needs API access to authoritative DNS to create/update the failover A record.

Cloudflare

• API token: Zone · DNS · Edit (+ zone read)
• Cloudflare Account ID
• Select the zone that will host your public hostname

cPanel / WHM

• WHM hostname and port (usually 2087 or 443)
• WHM username + API token
• Zone domain (apex), e.g. example.com

You can save reusable Cloudflare credentials under Settings → API providers and link them to pools without re-entering tokens.

Step 3 — Enrol the first member

On Overview → Add member:

After creating, copy the one-shot install command immediately and run it in the HAProxy Server — the enrollment secret is shown once.

The command:

• Downloads the agent bundle
• Runs balctl-agent.sh --enrol --key … --hostname …
• Writes /etc/balctl/agent.env
• Installs and starts balctl-heartbeat.service

Within a few seconds, the member tab should show a green heartbeat.

Step 4 — Set the public failover hostname

Settings or Managed DNS tab:

• Set DNS label (e.g. lb → lb.example.com)
• Choose orange-cloud (proxied) vs DNS-only as needed
• On Overview, Make active on the member that should receive traffic

Step 6 — Add a standby (High Availability)

Repeat enrollment on a second VM. Enable Automatic failover in Settings when ready for unattended promotion.

Pool workspace (Overview, Settings, DNS, DR, Monitoring)

Pool workspace

The pool page has a tab bar with three groups:

1. Overview (pool home)
2. Member tabs (one per enrolled host)
3. Pool tools (DR, Monitoring, Settings, Managed DNS)

Overview tab

For HAProxy pools, Overview answers:

• Is traffic on the active node?
• Are standbys ready?
• Will DNS move if HAProxy or the agent fails?

Hero panel: Traffic-flow diagram — Cloudflare/DNS → active HAProxy → standbys.

Actions:

• Add member
• Cut DNS to standby — manual DNS cutover to next ready standby (requires connected DNS)
• Settings shortcut

KPI tiles: healthy members, failover-ready count, backups, cron jobs, last failover time.

Member cards show Active vs Standby, heartbeat state, and Make active on standbys.

Settings tab

Failover hostname, proxied vs DNS-only, and Dynamic DNS sync live on the Managed DNS tab (not only Settings).

Managed DNS tab

• Failover DNS label and FQDN preview
• Orange cloud vs DNS-only
• Dynamic DNS sync — optional; updates A record when active member’s public IPv4 changes on heartbeat
• DNS connectivity test
• Current A record target IP

Disaster Recovery tab

Visible when the pool has 2+ members (HAProxy preset only).

Cross-member restore: Pick a target member, choose a snapshot from another host’s backups, restore scoped HAProxy files onto the target.

Requires Pro or active trial for cross-member restore.

Monitoring tab

Pool-wide alert settings and failover notification preferences (email when auto-failover promotes a standby).

Per-member monitoring is under each member’s Monitoring tab.

Protection tab

Only appears when 2+ cPanel members exist — not core HAProxy-only pools. Document separately if you mix cPanel hosts into an HAProxy pool.

Pool members & enrollment

Member tab layout

 

Click a member in the tab bar to open its workspace. Sub-tabs:

HAProxy-specific Management actions (install, reload, drain, TLS failover) are surfaced on Control panel and via Recipes — the dedicated HAProxy tab exists in code but is hidden until product-ready.

Enrollment security model

Each heartbeat must satisfy:

1. Bearer token — 48-character enrollment secret (hashed in D1)
2. CF-Connecting-IP — must match allowed source IP(s)
3. JSON hostname — must match enrolled hostname

Mismatch → 403 (IP) or credential errors.

Agent environment

Agent runs as root for HAProxy install, backup/restore, admin socket, and cert writes.

DNS failover & traffic cutover

Manual cutover

Make active on a standby member → ServerCTL sets it as primary and updates the managed A record to its public IPv4.

Cut DNS to standby on Overview → promotes next failover-ready standby (same DNS update, overview-oriented workflow).

Automatic failover

Enable in Settings → Balancer failover.

When enabled, ServerCTL periodically evaluates the active member. Promotion triggers when:

• Heartbeat age exceeds failover delay, or
• HAProxy is monitored and inactive

A healthy standby is promoted; DNS is updated; optional email alert fires.

Failover delay

Agents' heartbeat independently (~1s); failover delay is not the heartbeat interval.

Failover-ready criteria

A standby is ready when:

• Recent heartbeat within the failover window, and
• HAProxy is not down (when monitored)

Dynamic DNS Sync

Optional for HAProxy pools when the active member’s WAN IPv4 changes (DHCP/ISP churn). Each heartbeat can push the new public IP to Cloudflare without manual DNS edits.

Proxied vs DNS-only

• Orange cloud (proxied): Traffic through Cloudflare; good for HTTP/S when origin IP hiding matters.
• DNS-only (grey cloud): Clients connect directly to member IPv4 — required for raw TCP services (e.g. non-HTTP on custom ports).

HAProxy operations

Install & lifecycle

Jobs are enqueued to the API; the agent claims and runs them on the next heartbeat.

Admin stats socket (drain / ready)

Runtime backend control requires a Unix admin socket in haproxy.cfg:

stats socket /run/haproxy/admin.sock mode 600 level admin expose-fd listeners
stats timeout 2m

Enable via Recipe: Enable HAProxy admin stats socket or Enable admin stats socket action.

Requires socot + agent as root. This is not a public HTTP stats page.

Backend server states

From Management/topology table:

TLS (Let’s Encrypt on HAProxy)

Recipe: Let’s Encrypt (failover / HAProxy)

• Uses DNS-01 via Cloudflare for the pool failover FQDN
• Agent writes combined PEM: /etc/haproxy/certs/<hostname>.pem
• One-time operator step: add ssl crt /etc/haproxy/certs/<hostname>.pem in config, validate, reload
• Renew from Management or cron preset tls.acme_renew_force

The pool must have Cloudflare linked and a failover label set before the recipe applies.

Status tab

Shows live traffic from agent heartbeat enrichment — not a duplicate of the Overview topology diagram. Use for session rates, backend health columns, etc.

Backups & disaster recovery

What gets backed up

HAProxy backup job captures:

• /etc/haproxy/haproxy.cfg and conf.d/*.cfg
• /etc/haproxy/certs/*
• Let’s Encrypt material under /etc/letsencrypt/
• Paths referenced by ssl crt in config under /etc/
• Optional UFW rules (backup.ufw) — separate job

Storage: Per member S3.

Path pattern:

Restore flows

Same member: Restore Backups tab → pick snapshot → scoped restore → agent validates with haproxy -c → reload.

Cross-member (DR tab): Restore another member’s snapshot to a target VM — typically after an outage or a bad config push.

Fresh VM rebuild:

1. Enrol new/replacement member
2. Optional: Install HAProxy
3. Restore snapshot
4. Make active when ready

Standby provisioning

Provision standby from backup clones, HAProxy config from a backup onto a standby host — faster than manual copy for DR drills.

Recipes & scheduled jobs

Recipes (member → Recipes tab)

Recipes show steps, completion state, and optional disable actions (e.g. remove admin socket lines).

Cron & Jobs tab

Control-plane cron (UTC) enqueues jobs on the next agent heartbeat.

Common presets:

• HAProxy backup
• haproxy.reload
• TLS force renew
• failover.evaluate (pool-level failover check)

Separate from per-member backup schedule on Restore Backups — both can exist.

Job timeline

All agent jobs appear in Cron & Jobs with status: pending → running → completed/failed. Remote actions from Overview cards also enqueue here.

Agent reference

Heartbeat payload (HAProxy-relevant)

The agent sends JSON including:

• ip — declared/probed IPv4
• hostname
• haproxy block — monitored, active, topology, listeners, optional show stat summary

ServerCTL validates IP against enrollment and stores the latest row per node.

CLI essentials

sudo balctl_heartbeat.py --version
sudo balctl_heartbeat.py --provision-haproxy # local install
sudo balctl_heartbeat.py --update # from configured agent.zip URL
sudo journalctl -u balctl-heartbeat.service -f

Job loop

1. POST /api/agents/heartbeat
2. Server returns pending jobs
3. Agent executes, posts POST /api/agents/jobs/complete

Full agent docs: agents/README.md in the repo.

Troubleshooting & FAQ

Support bundle: If contacting support, include the pool name, member hostname, journalctl excerpt, screenshot of member health badge.

---

Appendix — Plan gating (for operators)

Linux Server Pools

Part 1 - Overview & Concepts

What ServersCTL hosting pools are

ServersCTL (serversctl.com) is the control plane for redundant server infrastructure: enrol Linux VMs with the ServersCTL agent, monitor heartbeats, cut over DNS between peers, run stack backups, and (on the cPanel preset) orchestrate account replication and live WHM transfers.

A server pool is one deployment in your dashboard — a set of members sharing failover DNS and pool-level settings. Members run what you actually install on each host. The dashboard exposes member tabs for OpenLiteSpeed, MariaDB/MySQL, Galera, and cPanel/WHM; each tab fills in when the agent detects that stack on that server.

ServersCTL does not host traffic. It moves DNS, queues remote jobs, and calls APIs where configured.

Pool Presets

Server pools are created using a preset template in the UI. This chapter is for the Generic Linux Server Preset. For HAProxy Server Pools, see the HAProxy chapter.

What runs on a member (stack compatibility)

Do not assume one VM runs every stack. Common deployments:

Core terminology

Architecture

Failover health: missed heartbeat beyond failover delay (10–120 s). No HAProxy systemd check on hosting presets.

All Linux Servers should use the Generic Server Preset when adding a pool. Only ever select the HAProxy Preset if HAProxy is installed on your server.

Create a Generic Linux pool

1. • Sign in at serversctl.com → Pools → Create Pool.

1. • Configuration preset: Generic Linux servers.

1. • Name the Pool.
   • Now, go to the pool. Pool  Overview → Add server. Choose — RHEL/Ubuntu - Enter hostname, allowed egress IP.

• 
• Click Create Enrollment" and copy the install command.

1. On the VM: 
   • Paste the install command into the console to install the agent. 
   • If you have existing installs of cPanel, OpenLiteSpeed, MariaDB etc. The agent will report this to the UI. 
   • When 2+ members run cPanel: pool Protection and Managed DNS tabs appear (see Chapter 1).
   • Optional: Configure DNS on Managed DNS for account-level cutover.

Add further members to the Pool

1. From the pool overview tab click "Add Member".
2. Name the member and supply the member's egress IP.
3. Copy the install command into the console of the server being added to the pool.
4. Repeat the process to add further members. There are no limits to the number of pools or members you may have.

How pool navigation works

Two layers on one screen

Protection and Managed DNS are pool settings. They float in the top tab bar above the member server tabs. They coordinate account replication, DNS cutover, and provider keys across the fleet — not operations on a single box.

Pool tab visibility (Generic Linux template)

Tab: Overview (first pool tab).

Purpose: Fleet-wide health — are agents reporting, are backups and jobs healthy across Linux servers?

What you see

Operator actions

• Add server — enroll another VM (see §18)
• Click a server tile or member tab — jump to that member’s Control panel
• Pool settings — shortcut to pool Settings tab

Tab: Protection (pool tab bar).

When visible: 2+ pool members where the agent reports cPanel.

Purpose: Account-level warm standby — scheduled WHM backup → Secure Storage → restore on a standby server, with optional DNS cutover per protected account.

What you see

Operator workflow

1. Ensure 2+ cPanel members and WHM API keys (Settings or Managed DNS → API providers).
2. Add protection — pick source account, target standby member, schedule (1h … 1mo), DNS TTL, DNS provider (Cloudflare or WHM).
3. Replicate now / Replicate protected (Pro) — on-demand sync.
4. Account Cut DNS — per-account A record swing to standby (coordinates with Managed DNS).
5. After DNS cut: post-failover hook on standby.

Relationship to member tabs

Protection is pool-wide orchestration; member cPanel is per-server WHM operations.

Replication Transfer

Replication can take anywhere from a few minutes to several hours, depending on the size of the account.

The source agent will package the account and split it into multiple chunks, which are securely stored temporarily in D2 storage. Once all chunks have been uploaded, the UI instructs the receiving agent to download them and begin the restore process.

After the restore has completed successfully, all stored chunks are automatically removed from S3. As a guide, a 1.8GB backup typically takes around 5 minutes to replicate. Please take replication time into account when configuring your schedule. If the account is large, you may need to replicate once per day or every few days to avoid overlap and ensure the process completes cleanly.

Tab: Managed DNS (pool tab bar).

When visible (Generic Linux): 2+ cPanel-detected members

Purpose: Pool-level DNS catalogue for protected accounts and optional dynamic DNS — WHM vs Cloudflare zones, record health, sync, import. The API keys listed here are for DNS only. Do not use your production WHM API key here. You must use Cloudflare or a cPanel DNS Cluster API Key.

What you see

Operator actions

• Connect Cloudflare and/or cPanel DNS API credentials
• Import existing Cloudflare records into the catalogue
• Sync WHM→CF after account changes on WHM
• Account Cut DNS from record rows (also available on Protection cards)
• Set failover hostname and enable DNS sync (when using pool-level cutover)

Protected DNS

The UI treats WHM servers as the source of truth and replicates changes to any linked DNS provider, as long as the account is marked as Managed. By default, the only record that will cut over automatically is the domain’s A record.

Multiple DNS Record Cut Over

You can configure the UI to cut over additional DNS records from the Protected Account DNS list. From here, you can specify A, AAAA, MX, and SRV records that should automatically cut to a standby server when the primary becomes unavailable.

Actions

The three‑dot menu under the Action column provides additional fine‑tuning options:

• Disable Managed DNS – When disabled, DNS records will not be updated or cut over during failover.

• DNS Only – During cutover, Cloudflare proxying will be disabled (grey cloud), ensuring a direct DNS‑level switch without CDN caching or WAF interference.

• Sync to Cloudflare – If you’ve added new DNS records in WHM’s DNS Manager, they will appear in the Protected DNS table and can be automatically pushed to Cloudflare.

Pool vs member DNS

Tab: Monitoring (pool tab bar).

Purpose: Pool-wide monitoring presets — distinct from per-member alerts on each server’s Monitoring tab.

Generic pool without Protection (0–1 cPanel members)

Infrastructure alerts section:

• Heartbeat miss thresholds, CPU/disk/service alert toggles
• Optional alert email recipients (account + team inboxes)

Generic pool with Protection (2+ cPanel members)

Protection DNS failover section (in addition to or instead of infrastructure, depending on layout):

Operator note

Configure per-member heartbeat and resource alerts on each server’s member Monitoring tab. Pool Monitoring is for fleet-level and protection DNS behavior.

Tab: Settings (pool tab bar).

Purpose: Pool identity, shared API credentials, danger zone.

What you see (Generic Linux)

What is NOT on the Generic pool Settings

HAProxy pools include Balancer failover on Settings.

Part 2 - Member workspace (per-server tabs)

Member tab bar (Generic Linux Server Pool)

Member Control Panel

Purpose: Host-level operations on this Server — OS family, uptime, services, quick actions, TLS.

What you see

Member Security

Tab: Security.

Purpose: Host firewall and SSH on this member.

What you see

Member OpenLiteSpeed

Tab: OpenLiteSpeed.
Sub Tabs: Overview, Recovery Wizard

For: VMs where OpenLiteSpeed is the web server — standalone OLS hosts.

Not for: Default cPanel/Apache hosting — expect a not-detected overlay on cPanel servers.

Overview

Web admin (:7080 link), KPIs, virtual hosts table, reload/restart/config test/backup/upgrade/LSPHP, logs.

Recovery Wizard

Also known as Cross‑Member Restore, this feature allows you to automatically take a full backup of an OpenLiteSpeed account, including SSL certificates and the database*. The backup is stored within your Pool API Storage, and the Recovery Wizard allows you to restore that backup to a different OpenLiteSpeed server.

If you have a DNS API Key scoped for the domain, DNS records can be updated automatically during the recovery process. Simply select the appropriate API Key when using the Recovery Wizard.

* Database restoration requires that no additional MySQL/MariaDB password is set when accessing mysql from the command line. If an additional password has been configured, the automated restore process cannot proceed, and the database will need to be restored manually.

Recipes & backups

Install OpenLiteSpeed, Harden OpenLiteSpeed on Recipes. Restore on Restore Backups (backup_openlitespeed, Pro).

Member MariaDB

Tab: MariaDB.
Subtabs: Overview, Databases

For: Dedicated DB servers or cPanel-managed MySQL on WHM hosts.

Standalone database server

Overview

Health, KPIs, schema cards, restart, config test, flush privileges, logical backup, harden, logs.

Databases

The Databases tab lists all databases discovered on the OpenLiteSpeed server. Databases are detected by scanning for common configuration files such as wp-config.php and parsing their contents.

Databases can be backed up individually or via cron. For a full account backup, use the Recovery Wizard.

cPanel-managed MySQL

If cPanel is on the same host: MariaDB tab shows a cPanel host notice — use member cPanel (§11) for account-level DB ops.

Galera (wsrep) (In Alpha)

When Galera is enabled, the agent will report the wsrep state. ServersCTL does not run quorum, SST, or writer election. DNS is active ≠ Galera primary.

Recipes & backups

Install MariaDB/MySQL, Harden the database. Restore Backups. Advanced recipes require Pro.

Member cPanel

Tab: cPanel.

For: WHM servers — the most common ServersCTL hosting workload.

Inner tabs: Overview · Operations · Accounts · Migrate & Recovery

Overview (inner)

DNS banner, protection topology (when account is protected), service badges, WHM audit summary.

Operations (inner)

Restart web/mail/cPanel, config check, WHM backup, harden, WHM API status, listeners, disk, metrics.

Accounts (inner) (Pro)

CRUD, suspend, terminate, backups, AutoSSL, one-time login. Free: read-only, 5 accounts cap.

Live Migrate & Recovery (inner) (Pro)

Live transfer, sessions, push copy. Bulk replication and schedules: pool Protection (§3), not this inner tab alone.

WHM Binding

Full WHM API when member matches pool host. Run WHM link check recipe after DNS connect.

Member Status

Tab: Status.

Purpose: Read-only health and readiness snapshot for this member.

Generic Linux member

Member Cron & Jobs

Tab: Cron & Jobs.

Purpose: Scheduled tasks on this member and visibility into recent job activity.

What you see

Common presets

Stack backups (backup.cpanel, backup.database, etc.), failover.evaluate where applicable.

Member Restore Backups

We are developing off-site backups. We currently only backup configuration unless stated in the UI. Contact us if you have questions.

Tab: Restore Backups.

Purpose: Snapshot catalog for this member — run backup, restore, delete.

Modes

Tab adapts to detected stack: cpanel, openlitespeed, database, or mixed.

Pro required for restore actions on stack backups. 

Member Recipes

In development - Only ever use recipes on clean servers. 

Tab: Recipes.

Purpose: Guided install and harden flows — one-click enqueue of multi-step agent jobs.

Examples by stack

Member Monitoring

Tab: Monitoring

Purpose: Per-member alert settings.

What you configure

Member Settings

Tab: Settings (member tab bar).

Purpose: Identity and location for this enrolled server.

What you see

WHM API keys for cPanel: prefer pool Settings / Managed DNS API providers; per-member WHM edit is available there.