terramate VS atmos

initContainers: - args: - >- curl -L https://github.com/terramate-io/terramate/releases/download/v${TERRAMATE_VERSION}/terramate_${TERRAMATE_VERSION}_linux_x86_64.tar.gz | tar xz command: - sh - -c env: - name: TERRAMATE_VERSION value: 0.4.5 image: curlimages/curl name: get-terramate volumeMounts: - mountPath: /home/curl_user/ name: terramate workingDir: /home/curl_user/ extraVolumes: - name: terramate emptyDir: {} extraVolumeMounts: - name: terramate mountPath: /usr/local/bin/terramate subPath: terramate readOnly: true

‍Terramate is an open-source IaC orchestration tool for Terraform, OpenTofu, Pulumi, Cloudformation, and others, that streamlines and scales your IaC workflows.

Nice, this looks close to https://terramate.io/ stacks

You might want to take a look at Terramate. Compared to other tooling such as Terragrunt we're not a wrapper that will lock you in yet another syntax. Terramate is a code generator and orchestrator that helps you to generate native Terraform that can be executed in whatever environment of your choice.

Another option for Terragrunt could be Terramate. It comes with Code Generation that helps you to automatically generate files such as Terraform, Provider and Backend configurations in various stacks (directories). The upside is that it always generates native Terraform code.

This can be done with a tool such as Terramate or Terragrunt (afaik Terragrunt doesn't come with change detection).

I'd love to add Terramate to the list of alternatives to Terraform Cloud!

That sounds like something Terramate helps with. I've been using it exactly for that purpose (code generation) and it made everything so much easier!

This is why we created atmos to make it easier to manage large multi-account architectures. As a result, our components are reusable across organizations, regardless of how many accounts and regions they operate, and we minimize the snowflakes. And we avoid code generation, which is hard to thoroughly test in an automated fashion. Without naming names, lots of tools for terraform rely on code generation, but I see it as an anti-pattern that should be avoided.

sorry did not find anything advanced. A better tool to make terraform scaleable is https://atmos.tools

Workspaces are incredibly practical, and we leveraging them at-scale with literally thousands of workspaces using atmos for terraform. There is so much FUD around workspaces that is either ill-informed or based on outdated information. Any company using terraform at scale will rely on tooling and conventions. It's up to that tooling to ensure you are using terraform safely. Atmos is one of those tools. I'm not saying that you have to use workspaces, but just that there's nothing wrong with workspaces themselves.

Check out atmos for a fresh take at managing terraform configurations and terraform workflows. Instead of managing HCL `.tfvar` files manually for configuration, it uses YAML, and supports concepts of imports (via deep merging), remote imports (anything supported by gogetter), mixins, inheritance, multiple-inheritance, vendoring of root modules, workflows, task runners (via custom subcommands), and much more. There's a bit of a learning curve and mind-shift required if coming from a Terragrunt background, but the experience is mindblowing after switching to it. Also, it's not limited to terraform.

We obviously don't have a project for your exact use case, but we have an open-source example repo that shows a fairly advanced scenario of using the Terraform Spacelift Provider https://github.com/spacelift-io/demo-preview-environments-manager, a simple quickstart of using it https://github.com/spacelift-io/terraform-starter and you can also see the CloudPosse Atmos project, for a very advanced scenario which generates lot's of Stacks based on your component specifications https://github.com/cloudposse/atmos.