OpenSRE is a self-hosted Python AI SRE agent that investigates production incidents, remembers past resolutions in Neo4j episodic memory, and maps blast radius via a service knowledge graph for authorized operations teams.
| Tool | swapnildahiphale/OpenSRE — memory-first, self-hosted AI SRE agent for automated production incident investigation |
| Category | AI operations / incident response automation |
| Primary Use | Automated root-cause investigation of incidents in owned environments (Kubernetes, AWS, Datadog, Grafana, PagerDuty, Elasticsearch) with recall of past fixes via memory-search |
| Safe Use | Operating, testing, and hardening your own infrastructure: labs, EKS/Kind otel-demo testbeds, and authorized internal reliability engineering; local-dev mode is explicitly documented as unsafe for network exposure |
| Telemetry Note | Read-only-by-design diagnostic queries against observability stacks; defenders should note agent API calls to Datadog/Grafana/PagerDuty and LLM traffic to Anthropic/OpenRouter, plus cleartext HTTP in make dev simple-mode visible on localhost |
OpenSRE positions itself as "the memory-first AI SRE": an open-source, self-hosted agent that automatically investigates production incidents, proposes root causes, and — the differentiating claim — remembers every investigation so the next similar 3am page starts with a known playbook. The README frames the value proposition tightly around three pillars: episodic memory of past incidents, a Neo4j knowledge graph modeling service dependencies and blast radius, and a catalog of 51 production skills covering the tooling most SRE teams already run. For security and reliability professionals, it is best understood as an investigation orchestrator rather than an exploitation tool: it reads telemetry, traverses topology, and diagnoses faults in environments you own.
The architecture is the most interesting part of the README. Agent orchestration is built on the Claude Agent SDK (claude-agent-sdk-python), with a root investigator spawning specialist subagents — a fan-out pattern familiar from modern agent frameworks. FastAPI provides the backend API with SSE streaming, so investigation progress lands in the console in real time. Next.js powers the web console (dashboard, memory browser, config editor), PostgreSQL stores configuration and agent-run state, while episodes themselves live in Neo4j alongside the service topology graph. LiteLLM is an optional proxy add-on (--profile litellm) that makes the LLM layer provider-agnostic — direct Anthropic is the default, with OpenAI and Gemini available through the proxy.
The episodic memory claim is concrete rather than marketing: the README describes a memory-search capability that surfaces past solutions mid-investigation. That is the mechanism by which the agent "already knows the playbook" — previous investigations are persisted as episodes in the graph, and when a similar fault signature appears, retrieved and injected into the current investigation context. Combined with dependency traversal in the Neo4j knowledge graph, the agent can reason about blast radius before it starts pulling logs, which is a genuinely useful ordering: scope first, evidence second.
Deployment is Docker-based and deliberately turnkey. make dev creates external data volumes if missing, then starts Postgres, config-service, Neo4j, the sre-agent, and the web console, with migrations running automatically; the console appears on localhost:3002 behind an admin token printed to the terminal. The maintainers deserve credit for a prominent security warning directly in the quick start: simple-mode runs cleartext HTTP with no rate limiting and no sandbox isolation, intended for localhost only, with a SECURITY.md hardening checklist required reading before any network exposure. That kind of upfront posture disclosure is rarer than it should be in self-hosted agent projects.
Integration surface is broad and operationally plausible. Beyond the core observability skills (Datadog, Grafana, Elasticsearch, PagerDuty, Kubernetes, AWS, Jenkins, Argo CD), OpenSRE meets responders where they work: a Slack bot via make dev-slack using SLACK_BOT_TOKEN and SLACK_APP_TOKEN, and a Microsoft Teams bot via make dev-teams listening on port 3978 with TEAMS_APP_ID, TEAMS_APP_PASSWORD, and TEAMS_TENANT_ID. Web console authentication supports Microsoft Entra SSO (confidential Web app, callback at /api/auth/callback, secret on config-service), with token login retained as break-glass — a sensible resilience detail.
What stands out for anyone evaluating agent reliability is the end-to-end testing story. Rather than asking users to trust the agent blindly, the project ships fault-injection harnesses against the OpenTelemetry demo app on a real EKS cluster: make e2e-setup-eks installs otel-demo, opens port-forward tunnels to Prometheus, Grafana, and Jaeger, and generates a team token. Tests like make e2e-test-cart (roughly 10% EmptyCart failures) or make e2e-test-ad inject faults via feature flags, then trigger and grade an OpenSRE investigation. A Kind-based local variant (make e2e-setup / make e2e-teardown) makes the whole loop reproducible without a cloud bill — this is also the ideal authorized sandbox for teams wanting to audit what the agent actually does before granting it credentials in production.
From a defensive and governance standpoint, deploying an SRE agent is a privilege-escalation question: the skills imply credentials for cloud consoles, monitoring APIs, and PagerDuty. The README's own guidance — simple-mode stays on localhost, hardening checklist before exposure — should be treated as a floor, not a ceiling. Sensible controls include scoping skill credentials to read-heavy IAM roles, routing LLM traffic through an inspectable proxy, and reviewing the SSE-streamed investigation logs the platform itself records in PostgreSQL. The Teams and Slack bots additionally create outbound webhook surfaces worth inventorying.
Operationally, the Makefile ergonomics are clean: make stop, make status, make logs, and make logs-agent for triage, make clean for teardown, make e2e-status for cluster and observability health. The repository is Python, Apache-2.0 licensed, sitting at 178 stars with active contributors and a public roadmap at opensre.in. A naming disambiguation note is worth heeding: this project is not affiliated with Tracer's OpenSRE at opensre.com — the maintainers include an explicit comparison page, which suggests they are aware the collision causes confusion in search results.
Where does it fit relative to commercial incumbents? The README names PagerDuty AI, Rootly AI, and Shoreline as comparison points. The honest differentiation is data residency and memory ownership: because it is self-hosted, episodic memory and the service topology graph never leave your infrastructure — a meaningful property when the material being investigated is incident data about production systems. The trade is that you carry the operational burden of Neo4j, PostgreSQL, and Docker service lifecycles yourself.
For authorized teams — internal reliability engineering, blue-team triage assistance, or building AI-assisted incident response in a lab — OpenSRE is a credible, well-documented entry in the emerging AI-SRE category. The combination of a real fault-injection test harness, explicit security posture documentation, and a memory architecture that compounds value over time makes it more evaluation-ready than most agent side-projects. Treat the simple-mode warning seriously, scope the credentials you hand its skills, and the Kind-based e2e path gives you a safe first deployment target.
swapnildahiphale/OpenSRE.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.