Spacelift Reviews

I used Spacelift for a proof of concept for a project approximately two years ago. Since Spacelift is a CI/CD tool for Terraform code, we have used it as a CI/CD tool for our Terraform Infrastructure as Code files. Whenever we need to build or make any changes on the servers, we use Spacelift and simply by making those changes manually on a configuration file in VS Code, as soon as we push the code to GitHub, it runs the code directly on Terraform without any manual intervention. This is the main use case for us.

We needed to automate our Terraform code so that we could simply write those code files in VS Code, and that code could be pushed from Git and GitHub so that it could directly configure the servers and make the changes on our cloud. That's how we started to use Terraform with Spacelift because earlier we were using all those things manually. We were simply writing those code and then running those Terraform plan and apply commands, and Spacelift does all these things for us. This is the main help from Spacelift.

Spacelift has other features beyond Terraform, including Ansible, Pulumi, Terragrunt, and it also helps with Kubernetes, although we haven't used it for the other tools. We have only used it for Terraform Infrastructure as Code, and it has helped us significantly. One standout feature compared to Terraform Cloud is the ability to apply policies. For example, we want to restrict engineers in our team from building servers with a particular SKU, such as in Azure, where we do not want to run servers with a SKU higher than the standard D4sv5. We can apply those policies in Spacelift, and the RBAC and access policies features are really excellent in Spacelift, which we do not find in any of the other competitor tools. The pricing is also competitive compared to Terraform Cloud.

The access policy features allow us to assign specific policies since we have three environments in our company: Dev, QA, and Prod. We assign policies so that anyone can run code from Dev and QA servers, but we assign a policy for specific people, such as managers, to run code in Prod. This is a very good feature from Spacelift that we have implemented for the access policy.

Spacelift has positively impacted our organization as a CI/CD tool for application deployment and development. Although we use other CI/CD tools like Azure DevOps and GitHub Actions, there wasn't a specific tool for Terraform Infrastructure as Code until Spacelift came along. It allows us to easily configure our servers and build a number of them on our cloud. While other CI/CD tools have started to include configuration features, Spacelift offers many other benefits that make it an excellent tool to use.

I would say that I think there are still some changes or improvements required on this tool. Pricing could be a little lower to make it a very robust tool, and it can improve areas in scalability and integrate some open-source tools. If there are no limitations on Spacelift, that would be ideal.

I have been working in my current field for more than ten years.

Spacelift is stable; we haven't found any bugs or errors, making it a very good tool to use.

The customer support is very good. The team at Spacelift is very helpful, and they possess ample knowledge. I have asked them various queries, and they provided perfect solutions along with good detailed documentation.

Previously, we used Terraform Cloud since it was free. However, when Terraform Cloud began to incur costs, Spacelift became our first choice. We switched because Terraform Cloud lacked good policies, such as access policies, and didn't provide much functionality. In contrast, Spacelift has excellent access policies that we can assign to different users, helping us significantly. I evaluated Terraform Cloud.

We have saved a lot of time since we started using Spacelift. There is no longer any manual integration or deployment on the servers. We are just pushing code from Git to GitHub, which then sends it to Spacelift, checking for drifts and starting continuous deployment. This is how we have saved time; earlier tasks that required two or three people now only need one resource to complete.

Spacelift is a paid tool; it's a GUI tool that we purchase directly from the Spacelift application. We cannot install or configure it on-premises or on any of our servers. During the proof of concept phase, I used the free version, which was available for a fourteen-day trial for two users. The next standard plan costs three hundred ninety-nine dollars per month for ten concurrent users. So, three hundred ninety-nine dollars per month is the cost for it. Compared to Terraform Cloud, this is slightly lower for approximately fifteen users. If your team comprises around fifteen to twenty members, everyone should use Spacelift; that covers all the costs.

The workflow has changed significantly. Earlier we were writing those Terraform files in VS Code and then running that command—Terraform plan, Terraform apply, and then Terraform destroy. However, as soon as we started to use Spacelift and simply push the code to GitHub, it provides us a GUI in the stack form, giving us detailed output. For instance, when the Terraform plan runs automatically, it asks before applying to confirm or discard. This is the main use case for us.

The GUI provided by Spacelift is very effective, giving us many features without the constant black screens that make finding errors difficult. It is easy for us to discover errors or blockers through this GUI. It also aids us in running commands which we normally execute from the terminal; now we can easily do it from the GUI as well. When we click on a task, we can run small commands and obtain the output. This functionality has significantly reduced our need for iterations to execute commands manually and wait for their results. As soon as we make a change in our code file and push it to GitHub, it automatically runs the plan and asks for our approval; upon giving approval, it makes the changes on the servers.

If you're looking to automate your Infrastructure as Code, then Spacelift is the best choice. Use Spacelift, and you'll notice the differences, whether you haven't used Terraform Cloud or if you have used it; you will find many great features in Spacelift that make it an excellent tool for Infrastructure as Code. I would rate this product a nine out of ten.

My main use case for Spacelift is to manage the infrastructure and accounts stacks for AWS and Azure. I use Spacelift to manage my AWS and Azure stacks by using Terraform integration with the Spacelift YML file, where I provision the spaces and manage the different stacks under the different spaces. For the state augmentation and state management, I use Spacelift since it is an independent solution, which proves useful for end-user developers to deploy their resources to the cloud directly.

Spacelift offers the best features that allow me to manage the stacks for different AWS and Azure accounts with different cloud providers while supporting additional services including OpenTofu, Terraform, Azure ARM templates, and CloudFormation.

The best feature I appreciate about Spacelift is that I can immediately back out the resources that are provided with Terraform in Spacelift. When I want to provision a new resource, I simply need to publish code and push it to the repository. The CI/CD automatically triggers the stack, and the stack allows me confirmation before deploying the resource and providing me with complete details of the resources that are deployed through the stacks. Regarding AWS and Azure specifically, they provide clear visibility for the resources that are deployed. With the templates and the secret variable management, I can keep everything secured.

Spacelift has positively impacted my organization by automating deployed nodes for Linux virtual machines, which provide high availability for stack deployment. The runs that have been triggered are quite fast, with no need for dependency on other teams to get them deployed or approved. The overall support for particular stack failures has been fabulous and has really impacted the company as it moves forward.

Regarding Spacelift specifically, if I have ten runs scheduled at a time, based on the particular Linux virtual machines that Spacelift uses, and if I have provisioned multiple nodes or Docker containers, all ten runs that are scheduled are executed quickly and saves a considerable amount of time rather than entering a pending state until the first run is completed. Therefore, efficiency has improved significantly.

Spacelift is good overall, but there are little explanatory aspects, such as navigating particular stacks, that are somewhat difficult to understand for newcomers, especially regarding the process, stack setup, and variable setup for deployments. If the documentation were more narrative, it would be much better.

The authentication for end-users requires access, and if there could be a read-only space where non-authorized users can see a non-authorized page, that would be helpful. A non-authorized user who wants to see some progress with read-only access could do so.

I have not yet interacted with the AI capabilities of Spacelift, but if they are improved, I think the Git-based tools will provide the same type of stability, and governance will be managed specifically as Spacelift is already taking care of governance for other applications and tools with respect to company policies.

I have been using Spacelift for the last two years.

Spacelift is stable.

Spacelift's scalability is quite good. Based on the requests and the Linux Docker machines I provision, it becomes more stable, and the runs happen very quickly.

Customer support has been good overall, but I have not engaged it much as I can fix things internally with the documents and different blogs available on the internet.

I previously used Terraform Cloud. I switched from Terraform Cloud to Spacelift based on pricing and the processing model, along with some additional features that Spacelift provides.

It was reasonably easy for my team to adopt and start using Spacelift, coming from a cloud background. If it were made more narrative, it would be easier for non-technical people to become accustomed to Spacelift. I describe the learning curve for Spacelift as straightforward but requiring some support at the initial stage.

I incorporated Spacelift directly with the Spacelift support and sales team rather than purchasing through the AWS Marketplace.

I have seen a return on investment. The metrics show that fewer employees are needed, money is saved based on past experiences with different cloud management or Infrastructure as Code management tools, and efficiency has improved significantly in terms of Infrastructure as Code deployment.

My experience with pricing, setup cost, and licensing has been based on the stacks, states, and resources provisioned or processed by Spacelift, which incurred different costs. The spaces have been a major aspect of managing things, and the contacts for the resources I provide internally in Spacelift are quite affordable, effective, and useful.

Only Spacelift was evaluated after Terraform Cloud.

I would advise others looking into using Spacelift to give it a try first, as you will love it. I suggest everyone look at Spacelift and dip their toes into it first, as you will definitely love it and will want to use it in the future. I gave this review a rating of eight out of ten.

My main use case for Spacelift is to automate and provision infrastructure as code, specifically by integrating our IaC Terraform with Spacelift.

A quick, specific example of how I use Spacelift with Terraform in my setup is that we write Terraform templates and integrate our Terraform code with Spacelift, using Spacelift to provision the infrastructure as a CI/CD tool, which helps us detect drift and assists with remediation.

I have more to add about my main use case with Spacelift, mainly on drift detection, as we are handling around 900 to 1,000 servers for Linux, so we use Terraform templates with Spacelift to manage our large-scale infrastructure operations.

The best features Spacelift offers include drift detection, multi-IaC support, and an open policy as code with Open Policy Agent.

The major impact that Spacelift has had on our organization is mainly related to detecting drift, especially as we maintain around a thousand servers. Additionally, Spacelift facilitates faster infrastructure delivery, allowing us to deploy our infrastructure with one click. Governance and compliance have improved, significantly reducing the majority of our security risks and enhancing the security of our current server strategies.

I mention the need for improvement of Spacelift.

I specifically wish to see improvements in Spacelift's user interface, making it more useful and easier for the team to understand. Additionally, enhancing the remediation capabilities on a broader scale would benefit our teams.

Another improvement I suggest is enhancing the templates for Terraform that can be integrated with Spacelift, allowing Spacelift to maintain default templates for these IaCs. If the team could integrate AI-assisted infrastructure operations, that would also be helpful.

I have been using Spacelift for around eight months, which is between eight to one year.

Spacelift is stable.

Spacelift can handle increased workloads well, managing more servers as our organization grows, and it is indeed scalable.

The customer support experience involves sending an email, but I have never requested customer support so far to resolve any issues.

I did not previously use a different solution.

My experience with pricing shows that the setup cost is reasonable, and the licensing also seems reasonable. The setup takes very little time since it integrates with our SVN or source code repository, and then we are good to go.

We have seen a return on investment, as the time saved for our DevOps team is significant. In terms of costs, identifying drift detection helps us remove unused servers, benefitting our application management.

My experience with pricing shows that the setup cost is reasonable, and the licensing also seems reasonable.

We have not evaluated any other options before choosing Spacelift.

After using Spacelift, I noticed a 90% reduction in time saved for repetitive infrastructure tasks, as the cloud configuration speed has doubled. For instance, if we previously deployed a server in ten minutes, we now do it in three to four minutes, along with increased deployment frequency for both Kubernetes and cloud deployments, greatly enhancing our metrics.

I have mentioned the improvements needed for Spacelift.

My advice for others looking into using Spacelift is that if there is a possibility of exploring more tools, they can consider alternatives, but from our experience, we are satisfied with what we are currently using. I would rate this product a 9 out of 10.

My main use case for Spacelift is that I primarily use it for Terraform, focusing on module versioning and deployment. Recently, we started exploring the blueprints option, but the primary focus remains on getting my Terraform landing zones defined and versioned in Spacelift and then testing the modules increment. As we have a GitOps approach, we want every commit and every pull request in Git to run through the set of tests that we have defined in the module in Spacelift. In summary, it serves as the main infrastructure as code tool.

A specific example of how I use Spacelift in my workflow is that we have landing zones in Azure based on the Microsoft concept of landing zones, where we define what we have in an application landing zone or a management landing zone and so on. These landing zones are built using Terraform modules, and each of those modules I have defined in Spacelift. Spacelift is tied to our Git repo, and that's where we develop the modules. For example, we have a SQL module where we have a SQL database module, SQL server module, and so on. They have versioning, and they're all tied together. If we want to deploy that specific SQL as part of a landing zone because an application needs it, we go to the application zone and plug in that module, referencing it from Spacelift. Then we deploy it, and especially if we want to release new features or new versions, we can simply increment the module version and go to the landing zone and do a small increment of the version of the module, which will deploy the new features. This represents approximately 90% of my use cases.

My use case for Spacelift fits into my workflow in many aspects through useful features such as the environments that you can pass between modules, which is not something that comes native in Terraform. Spacelift helps when I have variables that I want to pass between modules, between landing zones in our case, which are the stacks in Spacelift. When I say landing zone, that equals a stack, a Spacelift stack. It's valuable that I can pass the variables between stacks when I have some references, which isn't easily achievable with Terraform. Building the stack dependencies is another feature I use. It is excellent because I can execute stack updates based on module changes, then run that in a dependency flow and execute the change on each stack as I do it, so that I don't forget or miss any of that if I would have been doing this manually. I mentioned earlier that I started exploring the blueprints as well, but I still don't have a strong use case yet for that one in my team at least.

The best features Spacelift offers for my team include module versioning and testing. Whenever I want to touch on a module, add new functionality, change something, or do bug fixes, I do it directly in my Git or in my code editor. As I push the code, I can see direct feedback from Spacelift on whether the changes I've made are passing or breaking something. That's one of the best features for me. Then there's drift detection, which is really powerful because I can set a certain schedule for drift detection, and it lets me know if someone touches anything in the Azure console, for example, and it's not reflected in my Terraform. The policies are quite nice as well because they use the Snowbell standard for doing the policy as code, and I can set certain permissions for which team can work with which part of my stacks. The centralized workflow for infrastructure as code goes without saying.

Spacelift has positively impacted my organization in significant ways in terms of building infrastructure as code. There are other tools as well, but if I would run Terraform without any orchestrator such as Spacelift, it tends to be very tedious. It is positive in that it speeds up development with the automated tests that I mentioned earlier, giving me confidence that I don't normally have if I would be developing locally without such a tool as Spacelift. It also gives confidence to the people who are doing PR reviews, so when an engineer in my team creates something, changes something, or adds or removes from an existing module or stack, the PR review gives confidence that there are no breaking changes being applied through it. It speeds up the development and also speeds up deployment. Going back from a disaster recovery solution where I had to use it a couple of times, when everything is set, it's fairly quick to have full infrastructure back and operational in a matter of 20 to 30 minutes, as opposed to not using such tools. It has definitely affected speed of delivery, cost of delivery, and collaboration between teams or with other teams where we can provide rights to Spacelift, allowing for more gradual rights.

Regarding improvements needed in Spacelift, it's difficult to say because I have been using it for a while now and haven't seen many areas where I would want to see something new because much of what I missed at the beginning has actually been added. The engineering team behind Spacelift is very responsive whenever I submit a feature request, and there's a very good chance I would see it within the next year, which has been the case a couple of times for me. Perhaps the learning curve could be a bit steep if someone is completely new to Spacelift and only has experience with plain Terraform. Apart from that, perhaps some cost visibility of the infrastructure would be interesting to have, unless it's already there and I haven't seen it.

I would add about the needed improvements that a reporting solution where I could click through my stacks and see the costs driving my stack, such as whether it's the database, the sizing, or the VM types being used, could be an interesting feature to have.

I have used Spacelift for about three years.

Spacelift is stable.

Spacelift's scalability is very good as it scales very well with the environment because I can add agents to it with more workload, so it's quite excellent.

The customer support is fantastic as they reply over Slack immediately and get to work on a solution whenever I need them. It's one of the best customer supports I have seen from a company.

I haven't switched from any other solution, though I have used Terraform Enterprise in a separate project.

I have definitely seen a return on investment since time saved equals money saved as well.

I don't have much experience with pricing, setup cost, and licensing as that's handled by a different team. With pricing and setup costs, I don't have anything to compare it with regarding other tools, so I can't provide much information around the pricing.

Before choosing Spacelift, I evaluated only Terraform Enterprise as an option.

My experience with the drift detection feature is that we rely on it more than I would prefer. It's not ideal to detect drifts in my code, but every now and then somebody can make a change in a console to test something quickly or fix something quickly, and then they can forget to apply that change in the code if it should be there on a permanent basis. Drift detection will be there to tell me that something is off and I need to have a look, so if it's something related to permissions that I change and forget about permissions for a certain resource, it comes in very handy there as well.

I don't think there are any improvements needed in Spacelift that we haven't discussed, and I believe that covers everything.

I would advise others looking into using Spacelift to evaluate and make sure it's the right tool for what they're planning to do, but I would definitely recommend it very highly. I gave this review a rating of 9.

A specific example of how we use Spacelift for hosting those Terraform modules is that we use Terragrunt and call modules that are hosted in Spacelift. They're nested modules, so we have a high level module and then more specific modules. Sometimes they're shared modules that we use for different services.

It's useful to have the different versions with Spacelift because every time we make a change to a particular module, we can then choose to call that module from different environments. So if we are upgrading a module, we can gradually deploy it for different services. If there's an issue, we can always use an older version.

What I appreciate about the interface and the history tracking is that it's very clear. You can see all of the modules, search by name, see the history of any changes made, and it's very easy to use by choosing a particular version of the module. You can easily use that specific module from your code.

Spacelift has positively impacted my organization by making it very easy to manage the different modules with a very clear interface. You create so many different modules and so many different versions. Having a very easy way to navigate and search through them all, and the fact that you can actually see the commit ID and description really helps in discovering what was actually in that version of the module. This makes life a lot easier and more efficient.

Before we started using Spacelift, we were hosting the different modules in Git repositories, which means that you need to navigate to the specific Git repository to find that particular module. It's not designed just for Terraform modules, whereas Spacelift appears to be a far more focused tool that allows you to see all of the things that are relevant to maintaining a Terraform module in a very clear and easy way.

I give this review a rating of nine out of ten.

My main use case for Spacelift involves an implementation of a CI/CD pipeline that deploys Terraform code in AWS, so we manage all the profiles for the developers and manage all the AWS resources.

A specific example of how we use Spacelift in our pipeline is for Terraform deploys, managing all the resources with Spacelift and having profiles including developer profiles, DevOps profiles, and the cloud management profile, so we manage all the Terraform operations in Spacelift.

The best features Spacelift offers include the management capability where you can deny certain resources that developers can deploy. For example, if you want, you can deny the developer from creating a new VPC or a new cluster, allowing you to specify the resources that developers could deploy.

This feature impacts my workflow by making it easier because it facilitates the review of pull requests, as Spacelift will block anything that is not allowed, making it easier to review pull requests.

SpaceLift impacts my organization positively by giving more agility to the teams when they are deploying, allowing us to manage the AWS resources using Spacelift, so our cloud organization improves after this implementation.

The improvement I noticed after using Spacelift includes an increase in the deployment speed and in the review of pull requests, as we can make the deployments faster.

I think Spacelift can be improved by incorporating some kind of architecture for the resources being deployed, such as using AI to provide some drawn architecture.

Regarding Spacelift's AI capabilities, I think for reliability, if the platform is still running with no downtime or that does not impact the deploys, it is good output for reliability.

I have been working in this position for two years.

Spacelift is stable.

We did not scale the environment because we deployed it with the right sizing.

The customer support experience is good as they assist when we have some doubt or an issue.

My experience with customer support is that they are responsive and helpful, with the SLO and SLA being really fast to answer.

Prior to Spacelift, I used a simple GitHub Actions pipeline for Terraform deploying, and we switched because Spacelift provides more governance over Terraform.

Spacelift was deployed in a containerized cluster.

I can see the return on investment by specifically looking at the time saved.

My experience with pricing, setup cost, and licensing was really clear, so I did not encounter any problems.

We did not evaluate other options before choosing Spacelift; we just looked for Spacelift.

My advice for others looking into using Spacelift is that the governance is valuable. I would rate this review an 8.

I used Spacelift for one project with a duration of around six months.

Spacelift was used mainly for automating client infrastructure using Terraform and applying OPA policies to automate Terraform as an integrating tool that controls the whole infrastructure-as-code part.

In the project, we used a single GitHub repository for storing the infrastructure code and Terraform for the infrastructure-as-code. Terraform commands such as plan and apply were automated using Spacelift, which was integrated with OPA policies to check authorization, authentication, and whether the developer had permission to perform actions such as creating a virtual machine in the correct region. All this process was monitored using Spacelift.

We also integrated monitoring tools such as Grafana and Prometheus with Spacelift, but it was not completed unfortunately because the project duration ended. In summary, we used Spacelift for automating the infrastructure side and for role-based access control level user access to clients and applying the policies that they need in the organization.

Spacelift impacted our organization positively in several areas. Time-saving was achieved by eliminating the need for coordination runs. Before Spacelift, engineers had to coordinate via Slack to ensure no conflicting Terraform applies were running, saving each engineer roughly 30 to 45 minutes per deployment cycle just in coordination overhead.

Error reduction was another clear benefit, as the mandatory plan review step before any apply and OPA policies blocking non-compliant changes meant that a whole category of human errors simply could not happen. For team collaboration, Spacelift was transformative, allowing the whole team to safely propose, review, and apply changes, improving knowledge sharing across the team.

Before Spacelift, we averaged around two to three infrastructure-related incidents per month, such as state conflicts or unreviewed manual changes causing unexpected behavior. After adopting Spacelift, that dropped to roughly one every six to eight weeks, representing a 60 to 70% reduction in incidents. On time savings, our team of four engineers was collectively spending around six to eight hours per week on deployment coordination and managing run order manually, which came down to roughly two hours per week after Spacelift, freeing up meaningful time for actual feature work and improvements.

One thing that stood out unexpectedly was how well Spacelift handles drift detection in Terraform workflows, catching discrepancies early, which saved us significant troubleshooting time. The best features in my opinion are policies-as-code using OPA policies, stack dependencies, and Git-driven workflows. Overall, Spacelift bridges the gap between raw Terraform and enterprise-grade infrastructure management in a way that tools such as Jenkins or Cloud Build could not match natively.

One specific situation where drift detection really saved us was when a team member manually adjusted a security group rule directly in the AWS console during an incident, intending to revert it later but never did. Without Spacelift's drift detection, it would have silently remained out of sync with our Terraform state indefinitely. Spacelift flagged it within the next scheduled detection cycle, allowing us to review and reconcile the state before it caused compliance issues.

On stack dependencies, we had a layered setup where our networking stack had to be fully applied before the compute stack, and the compute stack before the application stack. Previously, we managed this manually, but with Spacelift's stack dependencies, we defined those relationships once, and it handled the trigger chain automatically, preventing partial deployment failures we used to deal with regularly.

The UI is one of Spacelift's stronger points, as the run view is clean and gives a clear timeline of what happened at each stage with easy-to-navigate logs. For team members who were not deeply technical on the Terraform side, the interface was approachable. The GitHub integration was seamless, as pull request comments with plan output worked out of the box, making code reviews much more collaborative. We also integrated it with Slack for notifications, so the team got alerts on failed runs or drift detection events without having to actively monitor the dashboard. That kind of passive visibility is underrated; it keeps everyone aware without adding overhead, and the integration ecosystem felt mature, not something bolted on as an afterthought.

Spacelift's documentation is quite thorough compared to some other tools in this space, with well-explained concepts and practical examples that cover edge cases. The documentation had enough working examples for us to adapt OPA policies without needing to dig through community forums or raise support tickets. The API support is also solid, exposing a GraphQL API that gives a lot of flexibility for automation, along with a Terraform provider for managing Spacelift itself as code, allowing version control of configurations such as stacks, policies, and contexts.

There are a few areas where there is room for improvement, particularly the initial setup and onboarding experience, which has a learning curve around understanding the concept of contexts. Better onboarding wizards would help new users get productive faster. The OPA policy writing is not very beginner-friendly either, and the error messages when a policy fails are not always clear. Pricing transparency is another area that could improve, as smaller teams or startups would benefit from clear tier breakdowns rather than having to go through a sales conversation.

I have been working in my current field for around three years.

My main advice would be to start with a clear understanding of your Terraform structure before onboarding Spacelift, as it works best when the infrastructure is reasonably modular. Spacelift fills a real gap in the infrastructure-as-code tooling landscape, providing a layer of workflow management that Terraform alone does not scale well without. For any team that has grown beyond a single engineer running Terraform locally, it is worth evaluating seriously, as the investment in setup pays off quickly in reduced incidents and improved confidence around infrastructure changes. I would rate this product an 8.

My main use case for Spacelift is using it as a Terraform collaboration provider tool.

Day-to-day, when I create a PR and get it merged, I am able to review the Terraform plan in Spacelift and then verify that it contains the changes that I am looking to make. If so, then I can apply it.

I also use Spacelift as a registry for Terraform modules.

Spacelift has positively impacted my organization because it works well; it allows everybody to collaborate in the same Terraform repo without stepping on each other's toes. I think that is the number one feature that is most required from using Spacelift or obtaining it.

The best features Spacelift offers include the ability to ensure that only one change is merged in at a time and ensure that everybody sees that unified page where it shows all of the runs that were already executed.

That unified view of runs helps my team because it allows anybody, whether they are technical or not very technical, to review the page and understand what got applied. It also makes it easy to use so that less technical or less DevOps engineers are able to create change requests into our Terraform.

I think an improvement for Spacelift would be a feature to run multiple stacks.

What I mean by that is if you have multiple stacks that rely on each other, it would be nice to detect that. For example, if you modify a module, it would be beneficial to have this capability.

There are no other improvements needed for Spacelift that I have not mentioned.

I have been using Spacelift for over one year, approximately two years.

My advice to others looking into using Spacelift is to use it and review all the TACO platforms and see if you really need it before purchasing it because for some simple workflows, you can get away with something simple. I would rate this product an 8 out of 10.

My main use case for Spacelift is infrastructure orchestration, where I'm currently working on S3 and SQS.

I use Spacelift with S3 and SQS by having a config setup for the S3 module as well as SQS, and we use GitHub actions. Whenever a Terraform module change on that git is done, a GitHub action is executed which in turn does an action on Spacelift that creates the plan, and then it executes the plan after the approval of the ongoing process where the IAM is used for three sets of people: the approver, who is the main administrator, and us, who will be the creators.

In Spacelift, the three steps we follow are plan creation, which is done via GitHub actions, and the approver has to go and approve this particular plan so that it can be available for execution. Currently, we have disabled any delete modules as we don't want to give that feature right now, and we are just focusing on read and write of Terraform modules.

The best features Spacelift offers include the drift detection feature, which is the most useful one for us, as well as comparison of the modules in versions, which we weren't able to do in our in-house tooling.

The drift detection has helped my team by addressing the major problem we faced in our internal tooling for infrastructure orchestration, which was if there were any manual changes done on AWS or the console itself missing the updates in the saved modules. Now these Terraform module versioning is done by Spacelift, which helps us compare what was there earlier and if any changes were done outside of the set system.

SpaceLift has positively impacted my organization by reducing a lot of confusion with the integration of Terraform modules, because a lot of our tooling involved direct and indirect Terraform module creations; now it is more streamlined for each and every resource that we control.

I'm new to Spacelift integration, and so far I have not seen anything that needs significant improvement; the UI is great, the functionality is great, and the drift detection features are great. There are more features that are onboarded every day, so for me, I have not hit any bottlenecks that need to be improved.

If I had to think of one area where Spacelift could improve, it would be the graph where we orchestrate, as the graph looks very complicated and complex, so perhaps it could be simplified.

I would find it helpful to have a flowchart similar to Argo CD so that we know what the orchestration metrics are and everything.

I have been using Spacelift for just over a year.

I purchased Spacelift through the AWS Marketplace.

My advice to others looking into using Spacelift is to be open to OpenTofu as well as Terraform so that you are able to identify issues and also understand the integrations that Spacelift provides. I rate this product an 8 out of 10.

We manage a lot of AWS deployments with Spacelift configs, so we have a main use case for it. We also use it for versioning and spinning up new environments.

Recently we used Spacelift for deploying our custom cloud code deployment platform on AWS. We used Spacelift to have A/B testing for different versions of our custom pipeline.

Spacelift has positively impacted our organization by speeding up our deployments and easing a lot of pain with infrastructure deployments, especially because a lot of teams are working simultaneously on the same code base using the same configs.

Every engineer in the team takes on their own infrastructure in their branch, controlling the version and using it without merging to master. Using Spacelift has improved collaboration and speed.

The best feature Spacelift offers is probably its versioning, which provides another layer above infrastructure as code. With versioning, you can do rollbacks and have different versions of the same infrastructure in different environments and jurisdictions, making it very useful.

We use the rollback feature all the time, especially every time we deploy to a new environment.

It would be nice to have out-of-the-box A/B testing with Spacelift because we still use some custom features for that.

Out-of-the-box A/B testing is the main thing I would like to add about the needed improvements, maybe with the custom solution not being declarative configuration but more like Pulumi.

I have been using Spacelift for four years already.

Spacelift is stable.

Spacelift's scalability is okay.

The customer support for Spacelift is okay.

I would rate the customer support for Spacelift as nine on a scale of 1 to 10.

We used Argo CD previously, and we switched from Jenkins because it is too hard to manage. Jenkins is even worse than Spacelift in terms of learning curve.

The learning curve for new users getting started with Spacelift is very steep.

I cannot share any metrics related to return on investment, such as money saved, time saved, or fewer employees needed.

My experience with pricing, setup cost, and licensing was that licensing was somewhat unclear when HashiCorp changed their own licensing.

We evaluated a few options with Pulumi before choosing Spacelift.

Spacelift does not handle compliance requirements in our organization.

SpaceLift helps with managing secrets and sensitive data very effectively, but we still use a lot of AWS secrets for production.

I already covered how Spacelift supports multiple teams or users working on the same infrastructure.

I monitor and troubleshoot issues within Spacelift through logging.

SpaceLift handles infrastructure drift detection by checking the version control.

We do not use Spacelift for supporting automation for repetitive tasks.

We integrate Spacelift with our existing CI/CD pipelines through GitHub Actions.

SpaceLift is deployed in our organization as a private cloud.

We mostly use AWS with Spacelift.

We did not purchase Spacelift through the AWS Marketplace as we have a custom setup.

SpaceLift's AI capabilities are very good regarding accuracy and reliability of output because it uses declarative configs, so most of the time they are accurate.

I would rate Spacelift a nine on a scale of 1 to 10.

I do not have any special advice to give to others looking into using Spacelift. Pulumi is also a viable option.