> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudeval.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Import an ARM or Bicep template
> Create a CloudEval project from local ARM JSON or a GitHub-hosted template URL.
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 **Projects**, then select **Create project**.
The dialog walks through three steps:
* **Project Details**
* **Review & Create**
* **Success**
Start with a **project name**, optional description, and cloud provider.
**Azure** is the practical choice today for ARM and Bicep-backed imports.
Paste a real template URL into **Template URL**. For example:
```text theme={null}
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:
```text theme={null}
.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.
The review step shows the selected `Template Source` as either:
* `File: `
* `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.
## 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.
```yaml theme={null}
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:
```json theme={null}
{
"$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](/reference/iac-project-config) for the full schema,
ignored paths, and examples for generated CloudEval folders.
Use [GitHub repository sync](/reference/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](/quickstart/create-a-project-from-a-github-url) for the focused browser flow, run [your first reports](/quickstart/run-your-first-reports), or move to [Review IaC before deployment](/workflows/review-iac-before-deployment) for a fuller end-to-end workflow.