Skip to main content

Cirdan: AI infrastructure cartographer and operations daemon. Graphify for live infrastructure.

Project description

Cirdan

Cirdan is a standalone AI infrastructure cartographer and operations daemon — Graphify for live infrastructure.

It installs into AI agents like a skill, but instead of graphing only code, it fingerprints and graphs the live infrastructure the agent can access: Docker, Kubernetes, cloud accounts, IaC, databases, telemetry. It watches that graph continuously, detects incidents, and gives agents (and humans) a structured way to understand and operate the system.

Cirdan fingerprints the system.
Cirdan graphs the system.
Cirdan watches the system.
Cirdan lets the agent operate inside the system using the access the agent already has.
Cirdan generates views only when the human asks to see something.

Install

uv tool install "cirdanops[all]"
# or
pipx install "cirdanops[all]"
pip install "cirdanops[all]"

Targeted installs: cirdanops[mcp], cirdanops[api], cirdanops[terraform], or combinations like cirdanops[terraform,mcp]. The Docker/Kubernetes/AWS/systemd adapters need no extras — they use the CLIs already on your PATH.

Two commands are installed:

Command What it is
cirdan Human/agent CLI
cirdand Long-running Always ON daemon

First map

cirdan map .

This fingerprints the environment (repo files and live runtimes the session can reach), builds the graph, and writes:

cirdan-out/
├── infra.html          # interactive infrastructure map
├── INFRA_REPORT.md     # plain-English report
├── infra.graph.json    # machine-readable graph for agents
├── fingerprint.json    # evidence-backed environment classification
├── access.json         # what this session can currently reach
├── services.json
├── dependencies.json
├── runtime-state.json
├── incidents/          # active.json + history.jsonl
├── views/generated/    # on-demand Agentic UI views
└── audit.jsonl         # everything Cirdan observed, generated, executed, verified

The access model

Cirdan inherits the agent's execution context. It is not a permission manager; it is a mirror. If the session can read the repo, run shell, reach /var/run/docker.sock, use kubectl, or call AWS — Cirdan can use the same context, and nothing more. Run cirdan access . to see the live capability report.

Commands

cirdan map .                        # full pipeline: fingerprint → graph → artifacts
cirdan fingerprint .                # what is this system? (with confidence + evidence)
cirdan access .                     # capability mirror for the current session
cirdan query "what depends on postgres?"
cirdan query "what broke in the last hour?"
cirdan query "what can the agent do here?"
cirdan show "show me the infrastructure map"
cirdan show "show checkout-api as a dependency graph"
cirdan show "show last night's incidents as a timeline"
cirdan incidents                    # detection pass + list
cirdan explain <incident-id|node>   # evidence-backed explanation
cirdan actions list <node>          # what can be done with current access
cirdan actions run <action-id> --yes
cirdan verify <act-record-id>       # did the system actually recover?
cirdan watch .                      # foreground event stream
cirdan serve-mcp                    # MCP server over stdio
cirdan install --project            # teach agents in this repo to use Cirdan

Always ON

cirdand serve                        # watch, refresh, detect, export — forever
cirdand serve --mcp                  # + MCP (stdio)
cirdand serve --http --mcp --host 0.0.0.0 --port 8090   # shared team server

The daemon runs supervised loops: access refresh, fingerprint refresh, graph refresh, Docker/Kubernetes event watching, telemetry ingestion, incident detection, verification, and artifact export. A crashing loop logs and restarts; it never takes the daemon down.

Agent integration

cirdan install --project             # all platforms, into this repo
cirdan install --platform claude     # .claude/skills/cirdan/SKILL.md + CLAUDE.md + .mcp.json
cirdan install --platform codex      # AGENTS.md + .codex/cirdan.md
cirdan install --platform cursor     # .cursor/rules/cirdan.mdc + .cursor/mcp.json
cirdan install --platform gemini     # GEMINI.md
cirdan install --platform generic    # .agents/skills/cirdan/SKILL.md + AGENTS.md

Installs are idempotent and never touch content outside Cirdan's own marker block. MCP tools include query_infra_graph, get_node, get_neighbors, shortest_path, get_recent_errors, get_logs, get_state, list_incidents, explain_incident, list_available_actions, execute_action, verify_action, generate_view, and more.

The graph

Every node and edge carries evidence and a confidence label (EXTRACTED, INFERRED, AMBIGUOUS, UNKNOWN):

{
  "source": "service:checkout-api",
  "target": "database:postgres-prod",
  "relation": "CONNECTS_TO",
  "confidence": "INFERRED",
  "evidence": ["DATABASE_URL references postgres://postgres-prod… in k8s/checkout.yaml"]
}

Cirdan maintains a static graph (what the repo says should exist: Compose, Kubernetes YAML, Terraform/OpenTofu, Helm, CI, SQL, nginx, systemd units) and a live graph (what actually exists: Docker Engine, Kubernetes API, AWS, systemd, Prometheus), merges them, and reports drift — declared-but-not-running, running-but-undeclared, degraded capacity, unhealthy state.

Actions and verification

Cirdan detects which operations are technically possible with the session's access (docker restart, kubectl rollout restart, systemctl restart, …), exposes them as graph-attached capabilities, executes only through the session's own tools, records pre/post state in the audit trail, and verifies the outcome (workload ready, health checks passing, error clusters quiet). There is no separate credential store and no privilege escalation.

HTTP API

With the [api] extra, cirdand serve --http exposes /health, /fingerprint, /graph, /graph/query, /services, /incidents, /actions, /views/generate, /audit, and a minimal OTLP/HTTP JSON receiver at /v1/logs. Add --mcp to mount the MCP server at /mcp.

Configuration

Zero config works. cirdan.yaml refines it — see cirdan.yaml.example.

License

Apache-2.0

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

cirdanops-0.1.0.tar.gz (91.0 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

cirdanops-0.1.0-py3-none-any.whl (109.5 kB view details)

Uploaded Python 3

File details

Details for the file cirdanops-0.1.0.tar.gz.

File metadata

  • Download URL: cirdanops-0.1.0.tar.gz
  • Upload date:
  • Size: 91.0 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.12.3

File hashes

Hashes for cirdanops-0.1.0.tar.gz
Algorithm Hash digest
SHA256 922b853c00c4b3385e081c0ad7b287b6f989e31c5abb19c7d522e626e1c03ee4
MD5 4b680e4c105e54442c73a8df29710d30
BLAKE2b-256 0146c48db43959de41779b5c1bcd19b42affe424aef7000e71a7247e504e939e

See more details on using hashes here.

File details

Details for the file cirdanops-0.1.0-py3-none-any.whl.

File metadata

  • Download URL: cirdanops-0.1.0-py3-none-any.whl
  • Upload date:
  • Size: 109.5 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.12.3

File hashes

Hashes for cirdanops-0.1.0-py3-none-any.whl
Algorithm Hash digest
SHA256 33e5bdfafded6c5499c78095f9a1cd98bf839d779c4bd77168535aae001a95c0
MD5 924524323c90df771107556147a0b752
BLAKE2b-256 3bbcdc4042227f9cb2599e349006215e10598de9ca68d127e2db47a7235f69c7

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page