terraform-aws-bootstrap VS terrateam

> At scale, many Terraform state files are better than one. But how do you draw the boundaries and decide which resources belong in which state files? What are the best practices for organizing Terraform state files to maximize reliability, minimize the blast-radius of changes, and align with the design of cloud providers?

1000% agree. I put together my version of standing up remote state in AWS in Github. https://github.com/aryounce/terraform-aws-bootstrap

Our use of Terraform splits state exactly as described primarily to keep the state refresh times reasonable.

Terrateam: After getting into some really big issues when running Terragrunt with Github Actions, I decided to look for a better CI solution. Terrateam is my CI/CD tool of choice here. Unfortunately as of December 2023, they increased their price from USD $175 to USD $496 monthly. Me being an existing customer I still pay the old amount (thank God!) Alternatively, you can look at solutions like Atlantis or spacelift.

Disclaimer: I am a co-founder of Terrateam (https://terrateam.io/) a competitor to Digger.

For anyone using Digger, are all of the enterprise features in the open source codebase? If you pay for digger, or you just paying for support and hosting? Or do they separate OSS from Community, Pro, and Enterprise plans?

Disclaimer: Co-founder of Terrateam.

For Terrateam[0], we have probably 70% of the enterprise offering but at around 1/10th the price. If there are any features that are deal breaker, feel free to reach out to me and we'll see what we can do. That being said, Spacelift is a much more luxurious piece of software than us. We are very utilitarian, but we have to rationalize that low price-point somehow.

[0] https://terrateam.io

Terrateam is an enterprise Atlantis alternative that lets you plan and apply all within pull requests and very minimal setup. We have a pretty active slack if you have any questions.

> It sure looks like AWS admin credentials are shared with Github, and also available to anything else in the diggerhq/digger action

I am a co-founder of Terrateam[0] which is a Terraform CI/CD as well. At the end of the day, you need to execute something to do these operations and having this component open source is important for auditing purposes. For Terrateam, we lean heavily into GitHub Actions so GitHub is at least managing any secrets and runs. One challenge is users could pin the Action that we publish to a specific version, but we also update it regularly and communicating to customers to update it is a challenge.

[0] https://terrateam.io

There are lots of options for this. I am co-founder of a product called Terrateam which makes it easy to slice up a mono repo for these usecases. We specialize in GitHub installations. But Spacelift, env0, and Scalr exist as options as well.

Many of the CI/CD tools take care of this. Terrateam tracks which plans are still valid after an apply and will force a re-plan. It also ensures that only one apply happens at a time.

We just released our self-hosted version available here: https://github.com/terrateamio/terrateam

I use Terrateam (disclaimer, I'm also a co-founder of it) does PR-level locks (but only on apply, or merge), and does apply serialization, and invalidates outdated plans on apply. You can plan as much as you want in parallel, though, because that does not impact the output. I don't think there are many other options for how to handle this.