How Reflex works

Reflex Local runs directly in your development environment. The VS Code extension provides inline warnings when it detects configuration patterns known to cause server issues in production — for example, a PHP memory_limit that will cause OOM kills under load, or a queue timeout shorter than the slowest scheduled task. The CLI exposes the same checks as a command you can run manually or integrate into git hooks. The pre-commit hook runs a fast subset of checks — config validation, environment parity checks — before every commit reaches your repository.

The philosophy is simple: the cheapest incident is the one that never reaches production. Every misconfiguration caught in a developer's editor is one fewer 3am alert. Reflex Local integrates into the existing workflow without adding friction — warnings appear inline, the CLI command exits non-zero when issues are found, and the pre-commit hook is a one-line addition to any project.

Configuration validation covers the most common PHP, nginx, and MySQL settings that cause production incidents. The environment parity checks compare your local .env against a manifest of required production keys — so you don't deploy code that will silently fail because a key wasn't propagated.

# Run Reflex Local checks before deploying
reflex check --env production --config ./config

# Output
✓  PHP memory_limit: 256M (recommended: 512M for this queue depth)
⚠  queue.timeout: 30s (your slowest job: crop_images averages 47s)
✗  APP_KEY not found in .env.production

Reflex Pipeline is the deployment and provisioning layer. It understands the state of your infrastructure before a deployment runs, and it knows what a healthy deployment looks like on the other side. Deployments are atomic — code changes are staged, health-checked, and promoted or rolled back automatically.

The Brain is involved in deployment decisions: if a recent deployment is correlated with an anomaly pattern, Reflex can initiate an automatic rollback before the incident escalates. This is the layer that makes Reflex a Forge and DeployHQ replacement for teams who want the intelligence layer and the deployment layer in one place.

Pipeline integrates with your existing git workflow. Push to your deployment branch, and Pipeline handles the rest: SSH connection, dependency installation, migration execution, asset compilation, process restart, and health verification. The health check is not a simple HTTP 200 — it verifies that PHP-FPM workers are accepting requests, that queue workers are running, and that database connectivity is live. Only when all checks pass does the deployment get promoted. If any check fails, the atomic rollback fires automatically.

# reflex.deploy.yml
deployment:
  strategy: atomic
  health_check:
    timeout: 30s
    checks:
      - php-fpm
      - queue-workers
      - database
  rollback_on_anomaly: true
  notify: slack

Reflex Server is the deepest telemetry layer — this is where the technical moat lives. The Go agent runs on every monitored server and collects standard metrics (CPU, memory, disk, network). On top of this, a PHP Zend extension instruments the PHP runtime directly — it can observe request lifecycle events, memory allocation patterns, and exception rates at the interpreter level. This is data that no external monitoring tool can access.

An nginx module provides request telemetry at the web server level. An eBPF base layer (Linux kernel 5.8+) provides system-call level observability for process lifecycle events. The combination of these four observability layers gives the Brain a complete picture of what is happening inside your server stack at any given moment.

The Go agent is a single static binary. It does not require a runtime environment, does not open inbound ports, and consumes less than 20MB of RAM at steady state. The PHP Zend extension is loaded via php.ini and adds approximately 2–4ms overhead per request — negligible in production workloads. All telemetry is transmitted over an encrypted outbound connection to the Brain cluster. No inbound firewall rules are required.

// Agent telemetry sample (emitted every 10s)
{
  "host": "prod-web-01",
  "timestamp": "2026-04-10T03:41:22Z",
  "php_fpm": {
    "active_processes": 8,
    "idle_processes": 4,
    "max_children_reached": false,
    "slow_requests": 0
  },
  "memory": {
    "used_pct": 73.4,
    "php_heap_mb": 412
  },
  "disk": { "root_used_pct": 61.2 },
  "nginx": { "active_connections": 43, "upstream_errors_1m": 0 }
}

The Brain is the repair engine. It receives a continuous stream of telemetry from Reflex Server, feeds it through pattern detection models, and generates repair hypotheses when anomalies are detected. A hypothesis is a structured object: the identified root cause, the proposed repair action, a confidence score (0–100%), and a risk classification (LOW, MEDIUM, HIGH).

Every repair hypothesis is run through a dry-run simulation before execution. The dry-run checks: is the playbook applicable to this exact server state? Will the repair action have any side effects that are not accounted for? If the dry-run passes, the Brain executes and monitors the recovery curve.

The entire process — from anomaly detection to resolution — typically completes in under 90 seconds. Every action is written to the immutable audit log. The Brain's decision-making is fully transparent: you can inspect the hypothesis object, the confidence score at decision time, the dry-run result, and the recovery outcome for every action ever taken on every server in your fleet.

// Brain hypothesis object
{
  "hypothesis_id": "hyp_01jbb3k9f4",
  "host": "prod-web-01",
  "detected_at": "2026-04-10T03:41:44Z",
  "root_cause": "PHP_FPM_OOM_KILL",
  "confidence": 94,
  "risk": "LOW",
  "playbook": "restart-php-fpm-with-memory-adjustment",
  "dry_run": { "passed": true, "side_effects": [] },
  "action": "EXECUTE",
  "resolved_at": "2026-04-10T03:42:51Z",
  "resolution_time_seconds": 67
}

The Dashboard is the control plane for humans. It shows you what the Brain is doing, what it has done, and what the current health state of every server in your fleet looks like. The real-time activity feed gives you a running log of Brain decisions, repairs executed, and health state changes.

The repair history is a complete audit trail — you can see every action the Brain has taken, the confidence score at decision time, the dry-run result, and the recovery outcome. For agencies, the white-label option lets you surface this as your own branded server health product to clients. The RBAC system lets you grant granular access — a client can see their server's health without being able to trigger manual repairs or see other clients' data.

The Dashboard is a read/control layer. It does not perform repair actions — that is the Brain's job. But it gives you the confidence that the Brain is working correctly, and the ability to intervene manually when needed. Every repair can be paused, confirmed, or overridden from the Dashboard in real time.