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

Term	Meaning
Pool	One site/deployment in the dashboard (D1 `sites` row)
Member	One enrolled VM (node) with hostname, allowed egress IP, and enrollment secret
Active member	The host whose IPv4 the managed DNS A record points at
Standby	Enrolled member not currently receiving DNS traffic
Failover hostname	Public FQDN clients use (e.g. `lb.example.com`)
Member template	Role at enroll time — for HAProxy pools use HAProxy balancer (`haproxy_edge`)

Architecture (high level)

Clients → DNS (Cloudflare / cPanel) → A record → Active HAProxy VM

↑

ServerCTL Worker updates DNS

↑

Standby HAProxy VMs ← agent heartbeats + jobs

Health for failover: A member is unhealthy when:

No heartbeat within the failover delay window (10–120 seconds), or
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 (show stat from heartbeat)

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