GitHub App

The CloudBurn GitHub App reads the resource changes that a commenter action attaches to the CDK diff, CloudFormation comparison, or Terraform plan it posts on your pull request, prices those changes against live AWS Pricing data, and replies with one cost report comment. It never clones your repository or reads your files — the pull request comment is the entire integration contract.

How it fits together

Two GitHub Actions, in three modes, produce the comments the app consumes:

Both actions also embed your repository's .cloudburn/usage-assumptions.json into the comment, so the app can price usage-billed services from numbers you control instead of guessing.

What the app reads from the comment

Alongside the readable diff, each action attaches a Resource Change Set to the same comment. GitHub does not render it, so reviewers see only the diff, and CloudBurn prices from that attachment rather than from the diff text.

Two consequences for your CI workflow:

• CDK needs the synthesized templates for both sides. A run that only receives a cdk diff text file still posts a valid payload, but its old and new pricing sides are unknown and every resource reports as unpriced. Point the action's before-template and after-template inputs at the base and head cloud assemblies to get prices. CloudFormation mode takes the same two inputs as template files or assembly directories. Terraform reads the plan file you already supply.
• A comment without a Resource Change Set gets no cost report. Comments from action versions that predate the payload, and comments written by hand, are not cost estimation requests. Update the action to its latest v1 release if reports stop appearing.

When an action cannot produce the payload, because a change set exceeds its size limit or the combined comment would exceed GitHub's comment limit, it keeps the readable diff and marks the failure. CloudBurn does not post an estimate from a missing or failed payload.

What the report contains

The cost report separates three confidence classes and never blends them:

• Fixed components price capacity that the diff declares outright, like an instance class or provisioned IOPS.
• Assumed components price workload-driven usage from your assumptions file, and each one names the value, unit, and scope that supplied it.
• Unknown components state which input is missing. A report with unknown components labels its subtotal as incomplete instead of pretending the cost is zero.

For a modified resource, the report also separates why the cost moved: an infrastructure-input change, an assumption change, or an AWS rate change. A modified component shows a delta only when both its old and new price are exact. An unknown price is never rendered as zero, as new, or as removed, and never enters a subtotal. Increases carry a leading +; decreases put - before the currency symbol.

If AWS Price List is temporarily unavailable, a component can be priced from a previously retrieved rate. Those rows are labeled (stale cached rate) and the report carries a matching note, so treat that estimate as provisional and re-check it on a later push.

Usage-billed services

A diff that adds a bucket or a Lambda function says nothing about how much traffic it will carry, so those charges come from your assumptions file rather than from the template. CloudBurn prices workload-driven usage for Amazon S3, SQS, SNS, CloudWatch Logs, EFS, Lambda, API Gateway, Kinesis, and networking — NAT gateways, VPN, Direct Connect, Global Accelerator, and Route 53 Resolver. The schema reference maps each one to the exact resource types and fields.

Everything else in the diff keeps its existing fixed-price treatment. No assumptions file means no assumed components — the app still posts the same cost report it always did.

What's next