Import an ARM or Bicep template

Use this path when you want to review infrastructure before deployment, share a template-backed workspace with a teammate, or skip live cloud credentials for the first pass. CloudEval’s strongest infrastructure-as-code path today is Azure ARM JSON. If your source of truth is Bicep, compile it to ARM JSON first and import the generated file.

What works today

Local ARM template file upload
Local multi-file IaC workspace upload
GitHub repository import through the CloudEval GitHub App
ARM template URL
Parameters file upload
Parameters file URL
Linked or nested ARM templates when the workspace includes .cloudeval/config.yaml
GitHub template URLs from the Azure Quickstart repo and similar public repos

If you provide a GitHub template URL, CloudEval can try to auto-detect a matching parameters file from the same repository when the naming pattern is recognizable.

Create a project from ARM JSON

Open the quick project flow

Open Projects, then select Create project.The dialog walks through three steps:

Project Details
Review & Create
Success

Add project details

Start with a project name, optional description, and cloud provider.Azure is the practical choice today for ARM and Bicep-backed imports.

Choose the template source

GitHub URL
Local JSON
Local workspace
GitHub repository

Paste a real template URL into Template URL. For example:

https://github.com/Azure/azure-quickstart-templates/blob/master/quickstarts/microsoft.compute/1vm-2nics-2subnets-1vnet/azuredeploy.json

CloudEval accepts common GitHub template URL shapes, including blob, tree, and raw GitHub content URLs.When the URL points at GitHub, the dialog also tries to find a matching parameters file automatically. You will see one of these states beside Parameters (optional):

Looking…
Found
Not found

If CloudEval finds one, it shows Auto-detected parameters file. You can still replace it with your own Parameters file URL (optional).

Use Upload Template File when the template already lives on your machine.Real examples:

./azuredeploy.json
./azuredeploy.parameters.json

The dialog accepts JSON uploads up to 2 MB. You can upload the template by itself or drop both the template and parameters files in the same step.

Use the workspace upload path when the template has linked or nested files.Example folder:

.cloudeval/
  config.yaml
azuredeploy.json
azuredeploy.parameters.json
nested/
  network.json
  storage.json
README.md

CloudEval preserves relative paths. That lets an entry template point at nested/network.json or nested/storage.json without flattening the workspace.

Use Import from GitHub repository when GitHub should remain the source of truth.The GitHub App flow asks you to choose:

a GitHub account or organization
a repository
a branch
an optional source root such as infra

CloudEval imports supported files from that root, reads .cloudeval/config.yaml when present, resolves linked templates, and starts diagram/report generation. Source files are read-only in CloudEval while the project is linked to GitHub. Edit in GitHub, then use Sync from GitHub or push to the selected branch.

Review and create

The review step shows the selected Template Source as either:

File: <filename>
URL: <template-url>

After you choose Review & Create, CloudEval creates the project, imports the source files, resolves the stack, and starts preparing the diagram and reports.

CloudEval stores the imported source, project metadata, and report outputs together so the whole review stays in one workspace.

CloudEval workspace showing imported ARM JSON, project files, report history, and source outline

Why this path is useful

Avoids live credential setup.
Works well for pre-deployment reviews.
Makes GitHub-hosted templates and local files behave like the same project workflow.

Configure nested ARM templates

For linked templates or repository-style uploads, add .cloudeval/config.yaml at the workspace root. The entry file is the visualization source. Linked files are dependencies.

version: 1
stacks:
  - id: main
    entry: azuredeploy.json
    parameters: azuredeploy.parameters.json
resolve:
  linked_templates: true
analysis:
  auto_resolve_on_import: false
  auto_refresh_on_resolve: true

Example entry template using relative templateLink files:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "name": "network",
      "properties": {
        "mode": "Incremental",
        "templateLink": {
          "uri": "nested/network.json"
        }
      }
    },
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2022-09-01",
      "name": "storage",
      "properties": {
        "mode": "Incremental",
        "templateLink": {
          "uri": "nested/storage.json"
        }
      }
    }
  ]
}

Expected result:

the file tree keeps azuredeploy.json, azuredeploy.parameters.json, and nested/** as separate files
CloudEval resolves the stack into a generated analysis bundle
diagrams and reports use the resolved bundle, not just the entry file

When the project is synced from GitHub, source files are shown read-only. The visible tree still uses repository-root relative paths; CloudEval does not add a synthetic repo/ folder. Use IaC project config for the full schema, ignored paths, and examples for generated CloudEval folders. Use GitHub repository sync for the GitHub App install flow, user mapping, webhook behavior, and troubleshooting.

Next step

Use Create a project from a GitHub URL for the focused browser flow, run your first reports, or move to Review IaC before deployment for a fuller end-to-end workflow.

​What works today

​Create a project from ARM JSON

​Why this path is useful

​Configure nested ARM templates

​Next step

What works today

Create a project from ARM JSON

Why this path is useful

Configure nested ARM templates

Next step