OpenTremor

A multi-tenant server that orchestrates LLM security analysis of infrastructure-as-code. Install an analyzer plugin for the IaC format you use. Client-led or fully server-side. REST and MCP on the same port.

Get Started API Reference GitHub

Start here

Pick the path that matches what you’re trying to do — everything else in these docs is organized around these four.

I want to use the dashboard Click-around web UI — no API calls, no code. Sign in and go.

I'm integrating via API or MCP Call the REST API or an MCP client from your own tool, script, or agent.

I'm deploying this for my team Install and run the server — Docker Compose or bare metal.

I'm contributing to the codebase Architecture, local dev setup, and the test suite.

What you get

Multi-tenant by design

Every org gets isolated resources, API keys, custom rules, and billing — one deployment serves many teams. Register an org, get a session or an API key, and everything downstream is automatically scoped to it.

Server-side or client-led analysis

Let the server call the LLM itself (POST /{analyzer}/{namespace}/analyze, one call in — a report out) or drive the ingest → analyse → submit loop yourself from any MCP client. Same data model either way.

Analyzer-agnostic core

The core model — AnalysisUnit, Finding — is analyzer-agnostic and ships with no built-in analyzers. Anything that can be split into independently-analysable units (Terraform, Ansible, Packer, Kubernetes manifests, …) is a self-contained plugin package, discovered at startup via a Python entry point.

Findings triage & cost control

Suppress, acknowledge, or mark a finding a false positive — it stays that way across re-scans and reports reflect it automatically. Cap an org’s monthly LLM spend and every analysis path (including webhook-triggered runs) is enforced against it, hard, before any LLM call.

GitHub App built in

Install the GitHub App on a repo and every PR gets analysed automatically — no CI workflow to write. The diff is analysed server-side and the result posted back as a PR comment plus a commit status.

No duplicate LLM calls

Units are keyed by SHA-256 of their normalised body, per org. The same module referenced across dozens of namespaces is analysed once and reused — cuts token spend and run time proportionally.

Example report

View sample output

Analysis Report — `b7e4a1f9`


Analyzer(s)	`terraform-plan`
Generated	`2026-07-31T09:12:00Z`
Resources analysed	3

Findings overview

2 finding(s) across 3 resource(s) — 1 critical, 1 high, 0 medium, 0 low, 0 info.

Title	Severity	Resource	Status
Trust policy allows any AWS principal to assume this role	CRITICAL	`aws_iam_role.ci_deploy`	OPEN
Storage encryption disabled on a new database instance	HIGH	`aws_db_instance.orders`	OPEN

Per-resource summaries

aws_iam_role.ci_deploy: Trust policy is far too permissive — fix before this ships.
aws_db_instance.orders: New instance created without encryption at rest.
aws_lambda_function.webhook_handler: No issues found.

Resource detail

`aws_iam_role.ci_deploy`

Action: update

CRITICAL — Trust policy allows any AWS principal to assume this role

Rule: TFSEC-030
Risk: Any AWS account — not just your CI provider — can assume this role and inherit its permissions.
Why it matters: A wildcard principal in a trust policy is one of the most direct paths to full account compromise.
Suggested next step: Scope Principal down to the specific OIDC provider/account ARN your CI actually uses.
Confidence: HIGH
Evidence: "Principal": {"AWS": "*"}
Tags: iam, privilege-escalation

`aws_db_instance.orders`

Action: create

HIGH — Storage encryption disabled on a new database instance

Rule: TFSEC-040
Risk: Data at rest is unencrypted; a storage-level breach exposes it directly.
Why it matters: This instance’s data typically includes customer PII and payment references.
Suggested next step: Set storage_encrypted = true (requires recreation if applied to an existing instance).
Confidence: HIGH
Evidence: storage_encrypted = false
Tags: rds, encryption

`aws_lambda_function.webhook_handler`

Action: create

No findings.

Generated by OpenTremor — analyzer: terraform-plan, namespace: b7e4a1f9

Every finding carries a persistent triage status — suppress one via PATCH /findings/{resource_hash}/{rule_id} and it disappears from future reports automatically. See Findings.

Two ways to run an analysis

One call, server-side

POST /{analyzer}/{namespace}/analyze with the raw input, an LLM backend/model, and either an inline API key or a stored org credential. Small inputs return the report directly; larger ones return a job to poll. The GitHub App uses this path internally.

Client-led loop

Ingest, then loop GET /{namespace}/resource/next → analyse → PUT /resource/{hash}/analysis yourself — from a curl script, the bundled example agent script, or any MCP-compatible client (Claude, Continue, Cursor). Full control over the LLM call.

Deployment options

In-Memory

Zero config. Start the server and go — state lives in-process. Perfect for local dev and short-lived CI jobs.

MongoDB

Persistent, multi-tenant storage: orgs, users, API keys, custom rules, LLM credentials, findings, billing usage — all org-scoped, with TTL-indexed telemetry.

Docker

Single-VM Compose stack or a Kubernetes Helm chart — see Deployment.

GitHub App

Install once per org, then every PR is analysed automatically — no CI workflow, no agent to configure. See GitHub App integration.

Quick links

Quick Start Up and running in under 5 minutes

API Endpoints Complete REST endpoint reference

Server-Side Analysis One-call analysis, no client loop needed

GitHub App Integration Automatic PR analysis, no CI workflow

LLM Agent Guide Step-by-step client-led analysis workflow