A connection is how CloudEval learns about the infrastructure you want to evaluate.
Three setup paths
CloudEval exposes three practical connection paths today:
| Path | Use it when | What CloudEval reads |
|---|
| Cloud sync | You want to evaluate deployed Azure resources | Azure Resource Manager metadata, deployment template exports, and topology signals from scoped resource groups |
| Infrastructure as code: single template | You want the fastest pre-deployment review | One ARM JSON template, plus an optional parameters file |
| Infrastructure as code: workspace | You have linked or nested templates, including a GitHub repository source | A workspace tree with .cloudeval/config.yaml, an entry template, parameters, and linked ARM files |
sync
source, while both infrastructure-as-code paths are template-backed sources.
The difference is how much source structure CloudEval imports before it builds
the diagram and reports.
What a connection stores
Depending on the connection type, CloudEval can store or reference:
- provider metadata
- sync configuration
- template URL, uploaded files, or workspace file paths
- GitHub repository, branch, source root, and commit provenance for GitHub-backed IaC
- visualization source from
.cloudeval/config.yaml
- scoped Azure subscription and resource groups
- connection health and test results
Why connections exist separately from projects
Connections answer the question, “Where does this infrastructure come from?”
Projects answer a different question: “Where does my team review, report on, and share this work?”
That separation matters because the same source model can be used to create or update project state over time.
For GitHub-backed infrastructure-as-code, GitHub remains the source of truth.
CloudEval imports files for analysis, keeps source files read-only in the code
view, and refreshes the workspace on push or manual Sync from GitHub.
Azure Cloud sync reality
For Azure Cloud sync, the current product supports:
- service principal credential validation
- subscription discovery
- optional resource group scoping
- least-privilege Cloud sync with management-plane read, deployment export, and optional Network Watcher topology permissions
Those workflows are materially deeper than the provider support currently visible for AWS or GCP, which is why the docs stay Azure-first.
Next step
Read Projects to see how connections become working spaces. If you are ready to set one up, use Connect an Azure environment for Cloud sync or Import an ARM or Bicep template for infrastructure as code. Last modified on May 24, 2026
