Proxy Aiops

Governed, audited AI-ops for Traefik, Caddy and HAProxy reverse proxies / load balancers — for AI agents (via MCP) and humans (via CLI).

Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by Traefik Labs, the Caddy project, HAProxy Technologies, or the HAProxy project. Traefik, Caddy and HAProxy are trademarks of their respective owners. MIT licensed.

proxy-aiops speaks to three proxy platforms behind one MCP server — Traefik (its API under /api/..., metrics-text counters via /metrics), Caddy (the admin API, default localhost:2019) and HAProxy (the Data Plane API v2 under /v2/..., HTTP Basic auth) — with the same tools working on all three. Each target in the config names its own platform; a name-keyed platform registry selects the API shape (auth + resource paths), and an explicit support matrix raises teaching errors for ops a platform genuinely cannot do — e.g. Traefik writes point you at its providers (file, container labels, orchestrator CRDs), never a silent no-op.

Every tool runs through a built-in governance harness (vendored, zero external dependency): audit log, token/call budget with runaway circuit-breaker, descriptive risk-tier labelling, undo-token recording, and output sanitisation.

Why this exists

• One server, three proxies — Traefik, Caddy and HAProxy in a mixed edge, spoken to through identical tool names. Adding another proxy later is a new platform descriptor, not a rewrite.
• Read the whole edge — version, entrypoints/listeners, routes (routers / caddy routes / frontends) with parsed hosts+paths, services and server-level upstream health, middlewares, TLS domain inventory, traffic/error counters, and the live config tree (snapshot + search).
• Flagship RCA analyses — transparent heuristics that show their numbers, never a black-box verdict: backend_health_rca (down upstreams → cause class L4/L6/L7/DNS/maint + action), cert_expiry_sweep (days-to-expiry buckets + per-platform renewal hints), error_rate_rca (5xx share vs the fleet baseline, dominant code → 502/503/504/500 cause), and route_conflict_analysis (shadowed routes, dead routes, redirect loops).
• Governed writes — caddy config set / delete / full load (the prior subtree/config is fetched first, so the recorded undo replays a real restore) and haproxy runtime server state (ready/drain/maint) and weight (undo restores the prior value) — all with dry_run previews; delete/load are risk=high with double confirmation at the CLI.

What this tool does, and does not, decide

It delivers proxy operations — reads and writes — accurately and efficiently, and records every one of them. It does not decide whether a write is allowed to happen. That is the agent's judgement, or the permission of the account you connect it with: give the HAProxy Data Plane API a read-only role, or scope down the Traefik/Caddy admin API you point it at, and the writes fail at the server — the place that actually owns the permission.

So there is no read-only switch, no policy file, no approval gate to configure. The one thing the tool guarantees is that nothing is silent: every call, over MCP and over the CLI alike, lands an audit row in ~/.proxy-aiops/audit.db, and reversible writes still capture their before-state and record an inverse.

Each tool declares a risk_level, kept in agreement with its [READ]/[WRITE] documentation tag by a test, and carried into the audit row as a descriptive tier — so a reviewer can see at a glance that a row was a high-risk delete. It is a label, not a gate.

Running a smaller / local model? See agent-guardrails.md — it lists the guardrails this tool now enforces for you (so you don't spend prompt budget restating them) and gives a ready-made system prompt for what's left.