The CloudBurn GitHub Action brings cloudburn scan to GitHub Actions workflows. It checks your Terraform and CloudFormation against the built-in rules, annotates findings inline on the affected files, posts a sticky comment on the pull request, writes a step summary, and can fail the job by severity.
Install it from the GitHub Marketplace. Releases are published to towardsthecloud/cloudburn-action; the source lives in packages/action of the CloudBurn monorepo.
The action bundles the same rule engine as the CLI, so there is no Node.js setup or npx install step, and results match cloudburn scan for the same inputs.
Quick start
Add this workflow to .github/workflows/cloudburn.yml:
name: cost
on: pull_request
permissions:
contents: read
pull-requests: write # for the findings comment
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: towardsthecloud/cloudburn-action@v1
This scans the repository root on every pull request. Findings appear as annotations and in a comment the action updates on each push, instead of adding a new one. The job stays green unless you set a fail policy.
On pull requests from forks, including Dependabot, GitHub gives the workflow a read-only token regardless of permissions. The action then warns that it could not post the comment and still emits annotations and the step summary.
Fail the job on findings
Set fail-on to fail for findings at or above a severity:
- uses: towardsthecloud/cloudburn-action@v1
with:
path: ./iac
fail-on: high
Set exit-code: true to fail on any active finding. When both are set, fail-on wins. When neither is set, the fail-on value from the config file passed with config applies. See Exit Codes for how the severity threshold works.
Choose which rules run
Use the rule inputs for a one-off selection:
- uses: towardsthecloud/cloudburn-action@v1
with:
enabled-rules: CLDBRN-AWS-EBS-1,CLDBRN-AWS-S3-1
comment: 'false'
Or keep the rule set and policy in a config file and pass it explicitly. The action never discovers .cloudburn.yml on its own, for the same reason the CLI doesn't in CI; see CI environments.
- uses: towardsthecloud/cloudburn-action@v1
with:
config: .cloudburn.yml
# .cloudburn.yml
iac:
enabled-rules:
- CLDBRN-AWS-EBS-1
fail-on: medium
Rule inputs are merged on top of the config file, the same way cloudburn scan flags override config values. See Configuration for every iac key.
Suppress accepted findings
Add a cloudburn-ignore comment immediately above or inside the resource. The reason after the rule ID is optional:
# cloudburn-ignore CLDBRN-AWS-EBS-1 migration scheduled
resource "aws_ebs_volume" "legacy" {
type = "gp2"
}
Suppressed findings never fail the job. They stay visible in a collapsed section of the comment and step summary, and the suppressed-count output reports how many there are. Inline suppressions work in Terraform and CloudFormation YAML; CloudFormation JSON cannot carry comments.
Inputs
The inputs mirror the cloudburn scan flags.
| Input | Description | Default |
|---|---|---|
path | Terraform file, CloudFormation template, or directory to scan | . |
config | Explicit CloudBurn config file to load (implicit discovery is off in CI) | |
enabled-rules | Comma-separated rule IDs to enable; when set, only these rules run | |
disabled-rules | Comma-separated rule IDs to disable from the AWS Core preset | |
service | Comma-separated services to include in the scan rule set | |
fail-on | Fail for findings at or above high, medium, or low | |
exit-code | Fail when any finding exists | false |
annotations | Emit inline annotations for findings with a source location | true |
comment | Post or update a sticky findings comment on pull_request events | true |
header | Heading used for the step summary and sticky comment | ## CloudBurn scan |
token | GitHub token used to post the pull request comment | ${{ github.token }} |
Invalid values fail the step before scanning: an unknown severity in fail-on, or a service that has no IaC rules.
Outputs
| Output | Description |
|---|---|
findings-count | Number of active findings |
suppressed-count | Findings suppressed by cloudburn-ignore comments |
failed | true when the active fail policy tripped |
result-file | Path to the full scan result JSON |
markdown | Rendered markdown report of the scan |
Use result-file to keep the full JSON result as an artifact:
- uses: towardsthecloud/cloudburn-action@v1
id: cloudburn
- uses: actions/upload-artifact@v4
if: always()
with:
name: cloudburn-results
path: ${{ steps.cloudburn.outputs.result-file }}
Annotations and comments
- Annotations. High-severity findings become error annotations; medium and low become warnings. Findings without a source location, or outside the workspace, appear only in the report table.
- Sticky comment. The comment is posted only on
pull_requestevents and needspull-requests: write. Reports longer than GitHub's comment limit are truncated with a pointer to the step summary, which always has the full table. - Tokens.
tokenaccepts the default workflow token, a personal access token, or a GitHub App installation token. The action updates only comments written by the token's own identity. If that identity cannot be resolved, it warns and skips the comment instead of editing someone else's report.
Scope
The action runs the IaC scan only. To evaluate resources running in a live AWS account, use cloudburn discover; CI/CD Integration shows how to schedule it in a workflow.
To see the cost of each pull request's infrastructure changes in dollars, rather than rule findings, use the CloudBurn GitHub App.
What's next
| Rules | See what each rule checks and how to remediate it |
| Configuration | Build a .cloudburn.yml for the config input |
| CI/CD Integration | Run the CLI in GitLab CI and other pipelines |