The Reflex agent (reflexd): architecture for operators

Reflex ships a single Go binary — reflexd — that installs like any other daemon. This post is the mental model operators ask for in sales calls: what runs where, what talks to the internet, and what never touches customer HTTP traffic.

Process model

reflexd is long-lived. It supervises its own reconnect loop to the Reflex control plane, maintains a command channel (install updates, rotate secrets, trigger policy sync), and schedules local checks with jitter so a fleet of servers does not thundering-herd your API.

Data classes (conceptual)

Inventory facts — packages, listening ports, PHP versions, FPM pools, nginx sites.
Health samples — CPU, memory, disk, load, per-service counters where exposed.
Log-derived signals — pattern matches and rate windows, not a wholesale log dump to the cloud.
Deploy markers — when Reflex Pipeline records a release, reflexd tags timelines so the Brain can answer "what changed before the spike?"

PHP depth without blocking requests

For PHP workloads, optional Zend extension instrumentation adds per-request memory and error classification inside the runtime. That path is designed to be off the request hot path where possible — budgets and sampling policies apply so production overhead stays within a trust envelope you can measure.

Security posture (high level)

Commands are typed and validated server-side before the agent executes.
Repairs execute through playbook boundaries — not arbitrary remote shell.
Updates are signed and verified (checksums / HTTPS distribution, depending on channel configuration).

Ask us for the agent threat model if your security team wants the long PDF version.

Failure modes we optimise for

Flaky networks — backoff, local queue for short offline windows, no silent data loss for commands that must eventually run or explicitly fail.
Half-upgraded agents — version negotiation and safe upgrade ordering.
Noisy neighbours on shared hosts — cgroup-aware memory signals where available.