Skip to main content
CloudEval needs source and cloud evidence to build diagrams, reports, and review comments. This page explains what enters CloudEval today, how GitHub-backed projects are synced, and which data-control options are current versus planned.

​
Current trust model

The current public product is a CloudEval-hosted service. For self-serve and Pro users, CloudEval imports source snapshots and generated evidence into CloudEval-managed project storage so the product can resolve templates, build graphs, run reports, and answer project-aware questions.
Team and Enterprise data-control options are roadmap direction. Treat the public Pro plan as CloudEval-hosted unless a contract or deployment agreement says otherwise.

​
Evaluation attribution

CloudEval integrates permissively licensed open-source tools as evidence sources alongside CloudEval project modeling, graph context, cost context, scoring treatment, reports, gates, exports, and agent handoff. CloudEval independently evaluates, normalizes, and presents results. These projects are independent of CloudEval; no affiliation, certification, sponsorship, or approval is implied. For pinned versions, source links, license links, third-party roles, and count methodology, read Evaluation methodology and attribution.

​
GitHub sync data flow

GitHub repository sync is designed to keep the repository as the source of truth while giving CloudEval a bounded review snapshot. When CloudEval syncs a GitHub project, it:
  1. Resolves the selected branch or ref to a commit SHA.
  2. Reads repository files through the CloudEval GitHub App installation.
  3. Preserves repository-relative paths under the selected source root.
  4. Skips excluded paths such as .git, .github, node_modules, .terraform, .env, Terraform state files, and CloudEval-generated folders.
  5. Imports a bounded snapshot for analysis.
  6. Stores commit provenance on the project so reports and PR comments can point back to the reviewed source.
Current sync limits are designed to keep repository imports focused:

​
What CloudEval stores for GitHub projects

CloudEval stores project metadata and a source snapshot. That can include:
  • repository owner/name, selected branch, source root, and commit SHA
  • imported source files needed for IaC analysis
  • .cloudeval/config.yaml when present
  • resolved topology and dependency context
  • report outputs, issue inventory, evidence metadata, and history
  • generated artifacts used by diagrams, reports, exports, and review comments
CloudEval does not store long-lived GitHub access tokens. It stores the GitHub App installation id and mints short-lived installation tokens server-side when it needs to list repositories, fetch files, sync a commit, or post an app-authored PR comment.

​
What stays outside CloudEval

For GitHub-linked projects:
  • GitHub remains the editable source of truth.
  • CloudEval does not push source changes back to your repository as part of sync.
  • Source files are read-only in the CloudEval workspace.
  • Pull-request comments and CI review are optional GitHub Actions workflows, not required for repository sync.
For Azure Cloud sync:
  • CloudEval reads scoped Azure management-plane metadata and exported deployment/topology evidence according to the permissions you grant.
  • It does not require broad contributor permissions for the documented least-privilege flow.
  • See Azure Cloud sync permissions for the current permission model.

​
AI and model context

CloudEval reports and review comments can include AI-generated summaries. The current public product uses CloudEval-managed model routing. The context sent for AI-assisted review is scoped to the active workflow, such as project metadata, selected source snippets, graph context, report evidence, and issue summaries. Use deterministic outputs when you do not want model-generated prose:
  • In GitHub Actions, set ai_summary: "false".
  • In the CLI, use --no-ai-summary for cloudeval review.
  • Export JSON or Markdown when another tool should inspect deterministic report data directly.

​
Future self-hosted and gateway pattern

For Teams and Enterprise, CloudEval is planning a customer-controlled deployment pattern where the CloudEval app, source snapshots, cloud evidence, and model routing can sit inside a customer-controlled boundary. The diagrams below split that future scope into two moments: the private data plane and model routing. Color legend:
  • Blue: CloudEval software running in the customer environment
  • Green: customer-owned private infrastructure, storage, or connectors
  • Amber: public source or cloud-provider endpoints outside the private boundary
  • Purple: customer-approved model routing and model-provider boundary

​
Future private data plane

In this planned data-plane model:
  • source snapshots and generated report artifacts stay in customer-managed storage
  • cloud sync runs through private-network or customer-approved connectors
  • CloudEval software runs inside the customer-controlled network boundary
  • public endpoints remain source systems or cloud-provider APIs, not the storage boundary for CloudEval project data

​
Future model routing

In this planned model-routing path:
  • AI summaries and chat route through an approved gateway instead of CloudEval-managed model routing
  • the customer controls which model account, key, gateway policy, and logging boundary are used
  • only scoped report, graph, issue, and source context needed for the active workflow is sent through the gateway
This is future scope. The current public Pro product remains CloudEval-hosted with CloudEval-managed storage and model routing.

​
Planned team and enterprise controls

CloudEval is planning deeper data-control options for Teams and Enterprise. These are not self-serve Pro capabilities today. These roadmap items are most relevant when your organization needs stricter data residency, private networking, enterprise model routing, or audit controls before connecting private infrastructure code or live cloud environments.
Last modified on July 11, 2026