Quick Start: Server-Side Analysis

The fastest path: hand the server a raw plan, an LLM backend, and a model — it ingests, analyses every resource, and hands back a report in one call. No loop to drive.

jq -n \
  --arg raw_input "$(cat terraform_plan.txt)" \
  '{llm_backend: "anthropic", model: "claude-sonnet-5", api_key: "sk-ant-...", raw_input: $raw_input}' \
  | curl -X POST http://localhost:8000/terraform-plan/my-namespace/analyze \
      -H "Content-Type: application/json" -d @-

Small inputs (≤ server.sync_analysis_max_units, default 5 units) return the report directly:

{"report_markdown": "# 🤖 Analysis Report\n...", "resource_count": 3, "quota_exceeded": false}

Larger inputs return a job to poll instead:

{"job_id": "b7e2...", "status": "queued"}

curl http://localhost:8000/jobs/b7e2...
# {"status": "done", "resource_count": 14, ...} — then fetch the report as usual

Omit api_key to fall back to a credential stored for the org — see POST /orgs/{org_id}/llm-credentials. For an analyzer with more than one rule variant (e.g. terraform-plan’s generic/aws), pass rule_type to analyze against a specific one instead of the default — the dashboard’s Analyze page exposes this as a “Variant” picker next to the analyzer selector, shown only when the chosen analyzer has more than one. Full reference: Server-Side Analysis.

Don’t know which analyzer applies?

Drop terraform-plan from the URL and hit /{namespace}/analyze/auto instead — each file in a diff is routed to whichever registered analyzer’s file_globs matches it (a single non-diff blob is matched by content instead):

jq -n \
  --arg raw_input "$(cat pr.diff)" \
  '{llm_backend: "anthropic", model: "claude-sonnet-5", api_key: "sk-ant-..."}' \
  | curl -X POST http://localhost:8000/my-namespace/analyze/auto \
      -H "Content-Type: application/json" -d @-

The response gains analyzers_used and a detections audit trail — see POST /{namespace}/analyze/auto. This is also what the dashboard’s Analyze page runs by default (its Analyzer picker’s “Auto-detect” option), and what the GitHub webhook uses for every PR.

If a file or blob doesn’t match any registered analyzer, and the optional blackhole analyzer plugin is installed and enabled for the org, it’s routed there for a generic, best-effort analysis instead of being left unmatched — the dashboard flags this in the report as “no analyzer found,” with a link to build a dedicated analyzer for that content type, since blackhole’s results aren’t guaranteed the way a real analyzer’s are.

---

Next steps

See Triage a Finding to suppress a finding, or Authentication to set up a real multi-tenant deployment. Prefer to drive the LLM call yourself instead? See Client-Led Loop.