An AI-powered infrastructure intelligence system that lives on your network, remembers everything, investigates anything, and talks to you like a colleague.
Explore Capabilities ↓Date: 2026-05-22 Version: Live and operational Status: Self-hosted, production-tested
An AI-powered infrastructure intelligence system that lives on your network, remembers everything, investigates anything, and talks to you like a colleague.
Not a dashboard. Not a monitoring tool. Not a chatbot with a Terraform plugin. It's a reasoning engine with direct access to your actual systems — built-in memory, multi-platform presence, and the ability to discover what's happening across 130+ hosts by SSHing into them, reading logs, querying databases, and correlating everything with your documentation.
You talk to it in Element or your terminal. It responds with evidence.
Every infrastructure team has the same problems:
Tribal knowledge dies when people leave. The person who built the Galera cluster knows why garbd is on the load balancer. Nobody else does. When they're on holiday at 2 AM and something breaks, you're reading wiki pages that haven't been updated since 2022.
Documentation drifts. Confluence says one thing. The running configuration says another. The Jira ticket says a third thing. Nobody knows which one is true until someone SSHes in and checks — and by then the incident is over.
Monitoring tells you what broke, not why. Your alerts fire. Grafana shows a spike. Loki has a thousand log lines. But nobody can quickly answer: "Did this happen before? What did we do last time? What's the topology between the affected nodes?"
AI tools for infrastructure are either toys or enterprise sales pitches. ChatGPT can write you a Terraform config. It can't SSH into your production hosts, read the actual state, compare it to what your docs say, and tell you exactly what's different.
This system solves all four. It is the person who was there. It remembers what happened, checks what's happening now, and tells you the truth.
Four layers of memory, working together:
This isn't "conversation history." It's a structured knowledge base about your infrastructure and your team.
The system doesn't just read documentation — it writes it, and it does something no other tool does:
AI source code analysis pipeline — point it at Java/Python repositories, and it analyzes the actual code and test files to generate comprehensive user documentation. It found features in our auction platform that nobody had ever documented — Reserve Temperature, cascading auto-bid responses, 3-level VAT resolution — because they existed in the code but nowhere in Confluence or Jira.
One brain, every channel:
Same memory. Same skills. Same capabilities. No matter where you talk to it.
ssheryl-field-notes-YYYY.md with a timestamp and context. Grep-able, append-only, no taxonomy tax. Nothing dies in chat history./etc/hosts. If the doc says one thing and production says another, the doc is wrong — it gets patched automatically. /etc/hosts is authoritative. Four stale IPs were silently wrong in the docs; they're correct now and stay correct. Also SSH-checks reachability to flag dead hosts before anyone notices they're missing./docs/ and /docs/knowledge/, adds anything new, removes anything gone. Zero human intervention. The catalog is always complete and always current.This is where the system does something no commercial tool even attempts. When a client reports "the site is slow" or "bidding isn't working," the system doesn't just check if the container is running — it traces the entire chain from user report to the exact line of source code:
The forensic chain:
1. Loki logs — pulls error patterns, counts, timestamps, and service labels across the entire stack. Filters out known noise.
2. Docker Swarm health — which node is running the service? Is it restarting? What image tag is deployed? Are there pre-bounce crash events (exit codes, OOM kills)?
3. Node resources — CPU, memory, disk, network on the affected host. Identifies resource contention before it becomes an outage.
4. HAProxy layer — is the load balancer healthy? Are backends up? What's the connection distribution?
5. WAR-to-code trace — every deployed service has a WAR file that encodes the git branch. The system maps the deployed WAR back to the git repository, finds the branch, and searches the source code for the exact class and line that throws the error.
6. Source code — reads the actual Java/Python code. If the error is in a framework class (com.sensibledevelopment.*), it checks the framework repo. If it's client-specific, it checks the application repo. Across 186 repos if needed.
Cross-references with Jira — checks if there's an existing ticket for the same issue, what was the resolution, and whether the fix actually landed in the deployed code.
Documents everything — each investigation becomes a case study in /docs/knowledge/ with the full trace, evidence at each step, and lessons learned. The system builds institutional memory of failure modes so the next time something similar happens, it already knows what to look for.
Concrete examples:
- Traced a C3P0 connection pool deadlock through Loki → Docker → database → source code → identified the root cause as non-primary-key UPDATE queries in row-level locking → recommended HikariCP migration.
- Identified a startup race condition where worker threads polled the database before task registrations completed, causing NullPointerExceptions in Reflection.newInstance().
- Diagnosed that "site is down but containers are running" meant Tomcat HTTP thread pool exhaustion (all 150 threads stuck) — no healthcheck configured, so Swarm couldn't detect or auto-recover.
This is forensics, not monitoring. It answers: "What broke, why, what did we do last time, and is the fix actually deployed?"
The system supports a disposable test stack pattern — collapsing a production auction stack (Docker Swarm + external MariaDB + NFS) into a single docker-compose.yml on testbed-app-0 that can be spun up, tested, and nuked on repeat.
What exists now:
- Test stack deployment — base stacks on production configurations, collapse external dependencies into compose files. Currently running hiddenbeanstesting (nginx + tomcat + mariadb + redis + push) on testbed-app-0.
- Playwright E2E test framework — automated browser tests targeting live test stacks. 11 tests passing on the first run. Reports archived as self-contained ZIPs with screenshots and traces.
- HAProxy routing by hostname — each test stack gets its own domain (testbed-site-N.v-auction.com) routed through a single HAProxy, no port conflicts, no DNS changes needed.
- Database import with binary data — handles large SQL dumps with inline GIFs/images, with proper max_allowed_packet handling that the default tooling gets wrong.
Where it's going: - More test stacks from different production configurations (Coffee, Pro, Podium) - Expanded Playwright test coverage — bidding flows, registration, payment - Pre-auction smoke testing — spin up a copy of the production stack, run the test suite, confirm everything works before auction day
This is still early days. The plumbing works, the patterns are proven, but the test coverage is thin. Worth mentioning because nobody else in the space is doing disposable test stacks that mirror production topology.
This is the differentiator that matters for production environments:
The system investigates, documents, and escalates. It does not modify, deploy, or change anything on production systems. This isn't a limitation — it's a safety philosophy. It means you can let it investigate anything without fear of making things worse. It can document the truth without becoming the cause of the next incident.
When a production change is needed, it escalates to a human with full context and evidence.
┌─────────────────────────────────────────────────────────────────┐
│ LLM API PROVIDER │
│ (OpenAI / Anthropic / Local) │
└────────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ MEMORY LAYER │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────┐ ┌───────────┐ │
│ │ Session │ │ Persistent │ │ Session │ │ Skills/ │ │
│ │ Context │ │ Memory │ │ DB (FTS5) │ │ Playbooks │ │
│ └─────────────┘ └──────────────┘ └────────────┘ └───────────┘ │
└────────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────────┐
│ CORE AGENT ENGINE │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────┐ │
│ │ Investigation│ │ Forensic │ │ Automation │ │ Document. │ │
│ │ Engine │ │ Chain Engine │ │ Delegation │ │ Generator │ │
│ └──────────────┘ └──────────────┘ └─────────────────────┘ └─────────────┘ │
└────────────────────────────┬────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ INTEGRATION LAYER │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Chat │ │ Infra- │ │ External │ │ Observ- │ │
│ │ Platforms│ │ structure│ │ Systems │ │ ability │ │
│ │ │ │ Access │ │ │ │ │ │
│ │ Matrix │ │ SSH │ │ Confl. │ │ Loki │ │
│ │ Element │ │ Docker │ │ Jira │ │ Grafana │ │
│ │ CLI │ │ MariaDB │ │ Git │ │ InfluxDB │ │
│ │ Email │ │ HAProxy │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘
A full interactive diagram is available at: SSHERYL_ARCHITECTURE_DIAGRAM.html
Commercial agents execute pre-defined workflows from chat. "Deploy service X" runs a Terraform plan. Useful, but narrow.
They don't SSH into arbitrary hosts. They don't have persistent memory of your infrastructure topology. They don't read Confluence, analyze source code, or write documentation. They're workflow executors with a chat interface. This is an infrastructure intelligence system.
Consulting slide decks about autonomous infrastructure. The actual implementation is "we'll get back to you in 18 months." This works today.
The open source ecosystem has individual pieces — agent memory frameworks (Memori), persistent agents (rho), Redis memory servers. But nobody has glued them together with SSH access, live investigation, documentation generation, and read-only safety.
| Capability | This System | Kubiya | ChatGPT | Open Source Fragments |
|---|---|---|---|---|
| SSH to 130+ hosts | ✓ | ✗ | ✗ | Partial |
| Persistent memory (4 layers) | ✓ | ✗ | ✗ | Partial |
| Cross-session search | ✓ | ✗ | ✗ | ✗ |
| Live log/database investigation | ✓ | ✗ | ✗ | ✗ |
| Forensic chain (symptom → source code) | ✓ | ✗ | ✗ | ✗ |
| Source code → documentation | ✓ | ✗ | Partial | ✗ |
| Read-only production safety | ✓ | ✗ | ✗ | ✗ |
| Multi-platform (Matrix/CLI) | ✓ | Partial | ✗ | ✗ |
| Self-learning (skills from experience) | ✓ | ✗ | ✗ | ✗ |
| Firewall intelligence | ✓ | ✗ | ✗ | ✗ |
| Confluence/Jira integration | ✓ | ✗ | Partial | ✗ |
| Disposable test stacks | ✓ | ✗ | ✗ | ✗ |
| Self-hosted, no vendor lock-in | ✓ | ✗ | ✗ | ✓ |
We recently pointed the system at our Java auction platform source code — three codebases, 2,200+ files — and asked it to write user documentation.
It found features that nobody had ever documented:
The system flagged its own uncertainty with [NEEDS REVIEW] tags — distinguishing between "the code says this" and "I infer the code probably does this." Then it generated a live wiki, emailed the review checklist to the team, and set up auto-rebuild on edits.
This is documentation written by the thing that actually runs, reviewed by the people who built it. Which is how it should have been all along.
A colleague who was there. It remembers every investigation, every fix, every configuration change, every "don't do that again" correction. Not session-to-session. Forever.
Live truth, not stale docs. It SSHes into your hosts and tells you what's actually running, not what Confluence says should be running. It cross-references and flags discrepancies.
Evidence, not speculation. Every answer comes with logs, configs, database queries, and SSH output. If it can't verify something, it says so and tells you exactly how to find out.
Forensic investigation from symptom to source. When something breaks, it traces the chain: user report → Loki logs → Docker health → HAProxy → deployed WAR → git repo → the exact line of source code. And it remembers what it found last time.
Documentation that writes itself. Point it at your code repos and your existing docs. It generates comprehensive user guides, finds undocumented features, and publishes a live wiki.
Disposable test infrastructure. Production stacks collapsed into self-contained compose files for spin-up/test/nuke cycles. Early days, but the patterns are proven.
Safety by design. Read-only means read-only. It investigates, documents, escalates. It doesn't break things. Ever.
Most infrastructure tools answer the question: "What's broken?"
This system answers the question that actually matters: "What happened last time something like this broke, what did we do about it, what's different now, and should I be worried?"
That question requires memory, investigation, reasoning, and context. It can't be answered by a dashboard or a monitoring alert. It needs someone who was there.
This is someone who was there. And remembers.
Built by Ian Morrison. Tested across 130+ hosts, multiple Docker Swarm clusters, Galera databases, HAProxy load balancers, and UFW firewalls. Read-only by design. Self-hosted. No vendor lock-in.