The CloudBurn extension runs the CLI against your saved workspace files and shows cost findings inline and in the Problems panel. It uses the same rules, configuration, and inline suppressions as your terminal and CI scans.
Scans run locally on the extension host. You do not need an AWS account, credentials, API key, or CloudBurn subscription. The extension does not upload source files, collect telemetry, or automatically change infrastructure.
Install
-
Install the CloudBurn CLI on the extension host:
brew install towardsthecloud/tap/cloudburnAlternatively, with Node.js 24 or later:
npm install --global cloudburn -
Install CloudBurn by dannysteenman from the Visual Studio Marketplace or Open VSX. The extension ID is
dannysteenman.cloudburn-vscode. VS Code's CLI can install it with:code --install-extension dannysteenman.cloudburn-vscodeIf you have a VSIX package, use Extensions: Install from VSIX instead.
-
Open and trust a workspace folder in VS Code 1.100.0 or later.
-
Run CloudBurn: Scan Workspace from the Command Palette, or save a
.tf,.json,.yml, or.yamlfile to scan its containing workspace folder. -
Open Problems and select a finding to navigate to its resource. Follow the rule ID link for an explanation and remediation steps.
For SSH, containers, and Codespaces, install the CLI where the workspace extension runs. A CLI installed only on your local computer is insufficient when the extension host is remote.
Try a finding
Save this Terraform file in your workspace:
resource "aws_ebs_volume" "example" {
availability_zone = "eu-central-1a"
size = 20
type = "gp2"
}
CloudBurn reports CLDBRN-AWS-EBS-1. Review the rule, change gp2 to gp3, and save again. The completed scan clears that finding.
High-severity findings appear as errors; medium and low findings appear as warnings. Findings without a source location appear at the workspace folder. Skipped files and scan failures produce workspace warnings and details in Output. The status bar shows the finding count or CloudBurn: incomplete when coverage is incomplete.
Commands
| Command | Command ID | Behavior |
|---|---|---|
| CloudBurn: Scan Workspace | cloudburn.scanWorkspace | Scan all local workspace folders |
| CloudBurn: Show Output | cloudburn.showOutput | Open scan details in Output |
| CloudBurn: Run These Checks in CI | cloudburn.openCiGuide | Open the GitHub Action guide |
In a multi-root workspace, separate folders can have their own settings. Overlapping folders share one scan owned by the outermost folder and its settings, avoiding duplicate findings.
Settings
| Setting | Type | Default | Purpose |
|---|---|---|---|
cloudburn.scanOnSave | boolean | true | Scan the containing workspace folder after saving a supported file or applicable configuration |
cloudburn.executable | string | "cloudburn" | Executable on the extension host's PATH, or an absolute executable path |
cloudburn.arguments | string[] | [] | Launcher arguments before --format json scan <folder> |
cloudburn.configPath | string | "" | Explicit configuration path, relative to the workspace folder or absolute |
An empty configPath preserves the CLI's upward discovery of .cloudburn.yml or .cloudburn.yaml from the workspace folder. Use an explicit path if the editor inherits a CI environment, where implicit discovery is skipped.
For example, to disable save scans and load a specific configuration:
{
"cloudburn.scanOnSave": false,
"cloudburn.configPath": ".cloudburn.yml"
}
You can still run CloudBurn: Scan Workspace manually with save scans disabled. Changing scanOnSave preserves existing findings and cancels pending save scans when disabled. File-change, settings-change, and manual refreshes still complete.
When scans refresh
Saving supported files triggers a folder scan after a short debounce. Saving an explicitly configured file also refreshes each referencing folder with scanOnSave enabled, including symlink aliases and files outside the workspace.
Without an explicit path, saving .cloudburn.yml or .cloudburn.yaml in the workspace folder or an ancestor directory refreshes that folder. A discovered configuration symlink is matched by its own path; set cloudburn.configPath explicitly to track a shared configuration's target outside the workspace.
Editor file creations, renames, and deletions refresh folders that have already been scanned, even when save scans are disabled. These events do not start a folder's first scan. Changes to the executable, launcher arguments, or config path also refresh previously scanned folders.
Supported files and limits
- Terraform HCL (
.tf) and CloudFormation JSON/YAML are supported. Terraform JSON (.tf.json) is not parsed by the CLI. - Scans read saved files, so unsaved buffers are not included.
- The extension requires a trusted workspace and files on the extension host's filesystem. Virtual workspaces are unsupported.
- Existing CDK-generated CloudFormation can be scanned. The extension does not run
cdk synthor map findings back to CDK source. - Each CLI scan has a 60-second deadline and a 16 MiB output limit.
Troubleshooting the CLI launcher
If the CLI is not found, check its installation on the extension host and set cloudburn.executable to its absolute path. CloudBurn: Show Output contains launch errors and scan details.
For a local CLI build or a Windows npm installation, launch the JavaScript entry point directly with Node.js 24 or later:
{
"cloudburn.executable": "/absolute/path/to/node",
"cloudburn.arguments": ["/absolute/path/to/cloudburn/dist/cli.js"]
}
For a monorepo build, the entry point is packages/cloudburn/dist/cli.js. On Windows, use node.exe; npm root --global identifies the parent directory of the installed cloudburn package. Escape backslashes in JSON paths. Arguments are passed directly without a shell, so shell syntax and .cmd wrappers are unsupported.
For a failed or timed-out scan, run the same command in a terminal on the extension host:
cloudburn --format json scan /absolute/path/to/workspace
Include --config /absolute/path/to/config when the extension uses an explicit configuration. Review parse diagnostics and skipped files before treating a scan as complete.
What's next
| Configuration | Share rule selection between editor and CI |
| GitHub Action | Run the same checks on pull requests |
| Scan Command | Review scan behavior and inline suppressions |