# Infracost: cloud cost estimates for Terraform, CloudFormation and CDK before you deploy

> Infracost reads infrastructure-as-code and reports what it will cost, in the terminal, the editor and pull requests. The repository is now a front door: the CLI, agent skills and IDE extensions live in separate repos.

**infracost/infracost** — Cloud cost intelligence for engineers, AI coding agents, and CI/CD 💰📉 Shift FinOps Left!

- Repository: https://github.com/infracost/infracost
- Website: https://infracost.io
- Stars: 12,541 · Forks: 692
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/infracost-infracost

## What Infracost answers, and for whom

The problem is timing. A Terraform plan tells you what will be created, changed or destroyed, but not what it costs. The invoice arrives weeks later, after the change is merged and applied. Infracost sits in that gap: it parses infrastructure code and produces a cost estimate before anything is deployed.

The audience is engineers writing infrastructure code, not finance. The README describes the toolkit as meeting engineers "wherever they work with infrastructure code", naming the terminal, the editor, the AI coding agent and the CI pipeline. The pitch is that every entry point talks to the same engine, the same pricing data and the same FinOps policies, so a check configured once appears in all of them.

That framing matters for adoption. This is not a dashboard you log into to reconcile last month. It is a step in the development loop, closer to a linter than to a billing tool. The README states support for over 1,100 resources across AWS, Azure and Google Cloud, plus usage-based resources such as S3 and Lambda.

## How the scan turns HCL into a monthly number

The mechanism visible in the repository is a pipeline in three stages: parse, price, report.

Parsing is provider-specific. The go.mod file pulls in goformation for CloudFormation and a set of AWS SDK v2 service packages (ec2, s3, dynamodb, autoscaling, cloudwatch, eks), which is what you would expect from a tool that needs to understand resource shapes rather than just read YAML. Terraform provider schemas are handled separately: the Makefile has a tagschema target that runs terraform providers schema -json and filters the AWS and Azure resource schemas down to entries carrying tags, tags_all or a tag block, writing the result to JSON files under internal/providers/terraform/provider_schemas. Those files are how the tool knows which resources can carry tags and therefore which ones a tagging policy can be checked against.

Pricing is where usage assumptions enter. The repository ships four top-level YAML files: infracost-usage-defaults.small.yml, .medium.yml and .large.yml, plus infracost-usage-example.yml. A static resource such as an EC2 instance has a list price and nothing more to guess. A usage-based resource does not, so the tool needs a default. The three size profiles exist precisely so that a team can pick one and know that every estimate in the organisation is built on the same assumption. The README calls these "usage-based resources" and names S3 and Lambda as examples.

Reporting is the last stage. The CLI prints a breakdown, and the same data feeds the editor extensions, the CI comment and the agent skills. The README notes that the IDE integrations are all powered by the Infracost Language Server, a standard LSP server, so any editor speaking LSP can integrate.

## Installing the Infracost CLI and running a first scan

The README gives package-manager installs for the three desktop platforms. macOS uses Homebrew:

```bash
brew install infracost
```

Linux uses an install script fetched over curl:

```bash
curl -fsSL https://raw.githubusercontent.com/infracost/cli/master/scripts/install.sh | sh
```

Windows uses Chocolatey:

```bash
choco install infracost
```

The README also points at GitHub Releases for a direct download. Note the split: the install script URL and the releases link both point at the infracost/cli repository, not this one. This repository is described as the front door to the project, and the README states that as part of the Infracost 2.0 release the codebase was refactored into the focused repositories it links to.

After installing, the documented next step is the interactive setup:

```bash
infracost setup
```

The README says this walks through authenticating, connecting your editor, configuring AI agent skills and wiring up CI/CD. It is the single command that configures the entry points.

For a first real use, point the CLI at a project. The README shows the scan command with no arguments, which suggests it runs against the current directory:

```bash
infracost scan
```

What you should expect is a cost breakdown for the resources in that project, plus FinOps recommendations. For a resource-level view, with cost drivers and policy details, the README directs you to the inspect commands instead. The examples directory in this repository contains sample projects under examples/terraform, examples/terragrunt, examples/cloudformation and examples/cf2tf, which is a reasonable place to try the tool before pointing it at production code.

## Where the estimate breaks down

The estimate is only as good as the usage assumptions behind it. A resource priced per request, per gigabyte stored or per gigabyte transferred has no cost until you say how much it will be used. The three defaults files exist because that number has to come from somewhere, and the tool cannot know it. If your workload does not resemble the small, medium or large profile, the estimate will be wrong in a direction you cannot see from the output alone.

Coverage is the second boundary. The README states support for over 1,100 resources across three clouds. That is a large number and still a subset. A resource outside the supported list contributes nothing to the total, so a project that leans on newer or less common services can produce a total that is confidently too low. The failure is silent by default, which is worse than an error.

Third, this is a pre-deployment tool. It reads code. It does not read your account. The README describes estimates for changes "before changes are deployed". If you want to know what you are actually spending right now, across resources that were created outside your IaC, a code-based estimator is the wrong instrument. The questions people search for that compare Infracost with cost-monitoring products are, in that sense, comparing two different jobs.

Finally, the repository layout itself is a cost of adoption. The README is explicit that the codebase was refactored into focused repositories and that "some pieces may consolidate back here over time". Issues and discussions for the project as a whole still live here. That is a reasonable structure for a project this size, but it means a bug in the CLI is filed somewhere other than the repo you found first.

## Infracost compared with Kubecost

The comparison that recurs in search data is Infracost against Kubecost, and the difference is the source of truth rather than the feature list.

Infracost reads infrastructure code. Its input is a Terraform, Terragrunt, CloudFormation or AWS CDK project, and its output is a cost estimate for the resources that code defines, produced before deployment and attached to the pull request that introduces the change. The value is in the review step: a reviewer sees the monthly delta next to the diff.

Kubecost works from a running Kubernetes cluster. Its input is the cluster itself, and its output is allocation of spend across namespaces, workloads and teams. That answers a question Infracost structurally cannot: what is the cluster costing right now, and who is responsible. It also cannot answer Infracost's question, because it has no view of code that has not been applied.

If your infrastructure is Kubernetes-heavy and defined through Helm charts and operators rather than Terraform resources, Infracost has less to parse and Kubecost has more to measure. If your infrastructure is Terraform-first and the review-time delta is the thing you keep missing, the ordering reverses. The two are complementary more than competing, and the honest framing is that they observe different stages of the same lifecycle.

## Licence, maintenance and the cost of staying current

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the SaaS product: the README describes Infracost Cloud as a dashboard where team leads and FinOps practitioners define tagging policies and guardrails, and that is a separate commercial offering from the open source CLI. Whether you need it depends on whether you want the policies centrally managed and enforced across every entry point, or are content configuring each one yourself. This is a description of what the README states, not legal advice; check the licence text and your own obligations.

The last push to this repository was on 2026-09-17, four days before this writing, and the repository is not archived. Releases are a different story: v0.10.45 is dated 2026-07-03, with a preview release on 2026-07-30 and v0.10.44 before it on 2026-04-06. So the front-door repository is being touched regularly while tagged releases of the CLI arrive on a slower cadence, roughly quarterly between 0.10.44 and 0.10.45.

Upgrade cost is mostly about the pinned toolchain. The Dockerfile installs a fixed list of Terraform versions (0.12.31, 0.13.7, 0.14.11, 0.15.5, 1.0.2, 1.0.10) and symlinks the minor-version aliases, with DEFAULT_TERRAFORM_VERSION set to 0.15.5. go.mod requires Go 1.26.0 with a toolchain directive of go1.26.6, and the Dockerfile comments that GOTOOLCHAIN=path is set to keep the two in sync and avoid silently downloading another toolchain. If you build the image yourself rather than using a release, that pairing is the thing to watch: a Terraform version outside the installed set, or a Go toolchain mismatch, will surface at build time rather than at scan time.

## Conclusion

Adopt Infracost if your infrastructure is defined in Terraform, Terragrunt, CloudFormation or AWS CDK and you want a cost number attached to a pull request rather than a monthly invoice surprise. Do not adopt it if your spend sits in resources the supported list does not cover, or if you need a live view of what is already running, since the estimate is built from code. Before rolling it out, run infracost scan against your largest Terraform project and check how many resources come back unpriced, then confirm which entry point your team will actually use, because the CLI, the IDE extension and the agent skills are separate repositories now.

## FAQ

### Is Infracost free to use?

The CLI is open source under Apache-2.0, so the tool itself carries no licence fee. Infracost Cloud is a separate SaaS dashboard for defining tagging policies and guardrails centrally, and the README treats it as its own product.

### What does Infracost do?

It reads Terraform, Terragrunt, CloudFormation and AWS CDK code and shows cloud cost estimates plus FinOps recommendations before the changes are deployed. The output appears in the terminal, the editor, an AI coding agent or a pull request comment.

### How do I install Infracost?

The README gives brew install infracost on macOS, choco install infracost on Windows, and a curl install script on Linux, with direct downloads from GitHub Releases as the alternative. After that, infracost setup walks through authentication, editor connection, agent skills and CI/CD.

### Is Infracost open source?

Yes. This repository is licensed Apache-2.0, and the README states the codebase was refactored into focused repositories including infracost/cli, infracost/agent-skills and the editor extensions. The hosted Infracost Cloud dashboard is a separate offering.

### How does Infracost compare with Kubecost?

Infracost estimates the cost of infrastructure defined in code, before it is deployed, and attaches the estimate to a pull request. Kubecost measures spend in a running Kubernetes cluster and allocates it across namespaces and workloads. They observe different stages rather than solving the same problem.

### Does Infracost work in VS Code?

Yes. The README lists infracost/vscode-infracost for VS Code, Cursor and Windsurf, alongside JetBrains, Neovim and Zed extensions. All of them are powered by the Infracost Language Server, so any editor that speaks LSP can integrate.

## Sources

- [infracost/infracost on GitHub](https://github.com/infracost/infracost)
- [License: Apache-2.0](https://github.com/infracost/infracost/blob/master/LICENSE)
- [Project website](https://infracost.io)
- [README](https://github.com/infracost/infracost/blob/master/README.md)
- [Releases](https://github.com/infracost/infracost/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/infracost-infracost