This page is the shortest stable description of how CloudEval is structured.
Core objects
| Object | What it represents | Why it matters |
|---|
| Connection | A source of live cloud data or infrastructure code | It tells CloudEval what to analyze |
| Project | The main working unit | It holds files, topology, status, reports, and sharing |
| Report | A generated evaluation output | It surfaces cost or architecture findings |
| Sharing state | Visibility and access configuration | It controls who can see or collaborate on a project |
Connection types and setup paths
CloudEval stores two internal connection categories:
Users see three setup paths:
| User-facing path | Internal category | Source shape |
|---|
| Cloud sync | sync | Deployed Azure resources read from scoped subscriptions or resource groups |
| Infrastructure as code: single template | template | One ARM JSON template and optional parameters file |
| Infrastructure as code: workspace | template | Multiple 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:
Collaboration roles
Projects support:
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