Skip to main content
This page is the shortest stable description of how CloudEval is structured.

Core objects

ObjectWhat it representsWhy it matters
ConnectionA source of live cloud data or infrastructure codeIt tells CloudEval what to analyze
ProjectThe main working unitIt holds files, topology, status, reports, and sharing
ReportA generated evaluation outputIt surfaces cost or architecture findings
Sharing stateVisibility and access configurationIt controls who can see or collaborate on a project

Connection types and setup paths

CloudEval stores two internal connection categories:
  • sync
  • template
Users see three setup paths:
User-facing pathInternal categorySource shape
Cloud syncsyncDeployed Azure resources read from scoped subscriptions or resource groups
Infrastructure as code: single templatetemplateOne ARM JSON template and optional parameters file
Infrastructure as code: workspacetemplateMultiple files, linked or nested ARM templates, and .cloudeval/config.yaml
This distinction matters for automation. A multi-file IaC workspace is not a new live cloud connection type; it is a richer template-backed source that resolves to the same diagram and report pipeline.

Project types and status

Projects can track status for:
  • sync
  • architecture
  • cost
  • unit tests
A project can also expose latest report metadata and dashboard summaries for cost and architecture.

Share views

CloudEval share links support these read-only view modes:
  • preview
  • code
  • split

Collaboration roles

Projects support:
  • owner
  • editor
  • viewer

Next step

Use Report types and statuses if you need more detail on output structure, or Share links if you are documenting access behavior.
Last modified on May 22, 2026