terraform-starter VS atmos

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.

Use our starter repository to play with Spacelift (guide)

If you're looking for TFC alternatives where you can manage your own state, https://spacelift.io is another option. We've got a tutorial walking you through creating an account and using Spacelift here if you wanna give it a try: https://github.com/spacelift-io/terraform-starter

Spacelift goes a few steps further though and puts policy-as-code in the center of its value proposition and builds a consistent, robust policy framework. Apart from providing a comprehensive automated change review and ensuring compliance of your Terraform changes, Spacelift uses the same approach to allow you to declare rules around account and project access, handling push notifications, starting runs and triggering tasks, and creating relationships between projects. It also provides the Policy Workbench, which lets you view past executions of your policy – including the inputs and decisions that have been made – and lets you interactively edit your policy, while simulating its execution on these previous inputs. You can use our starter repo to quickly provision a bunch of policies and get a feel for how you can work with them in Spacelift.

PS: If you want to quickly check out Spacelift (literally 15 minutes of your time) come and take a look at our Starter Repository!

Feel free to [schedule a chat/demo with us](https://spacelift.io/schedule-demo.html) or tu play with our starter repo to [learn more](https://github.com/spacelift-io/terraform-starter).

Hi HN!

We are the team behind Spacelift (https://spacelift.io/). Spacelift is the CI/CD for infrastructure-as-code, be it Terraform, Pulumi, CloudFormation or Ansible (coming soon), and policy as code. It enables collaboration, automates manual work and compliance, and lets teams customize and automate their workflows.

Here’s what you can do with Spacelift

- Build sophisticated Git-based workflows

- Use Open Policy Agent to declare rules around your infrastructure, access control, state changes, and more

- Author and maintain reusable modules for your organization; we even have a full CI solution for modules to make sure they’re healthy

- Declare who can log in (and under what circumstances) and what their level of access to each of the managed projects should be (SAML 2.0 SSO out of the box!) using login and access policies respectively

- Use Spacelift’s trigger policies to create arbitrary workflows and dependencies spanning multiple infrastructure-as-code stacks

- Manage stacks, contexts, modules, and policies in a declarative way using Terraform or Pulumi

Before Spacelift, we built bespoke solutions (e.g., Geopoiesis, https://www.reddit.com/r/Terraform/comments/fu6pj1/geopoiesisio_anyone_knows_something_about_it/), currently used by two of the largest European scaleups.

In the past few months, we’ve been onboarding our first customers and making sure everything works as expected. You can check out our starter repo at https://github.com/spacelift-io/terraform-starter. It's an easy way to learn all of Spacelift’s capabilities in 15 minutes without tapping into your own cloud resources. We’d love your thoughts on our approach and anything that has worked or hasn’t worked for you.

P.S. We are hiring https://spacelift.io/careers

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.