Senior Software Engineer at a tech vendor with 1,001-5,000 employees
Real User
Top 10
Jun 15, 2026
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.
I use Spacelift in my current environment for deploying Terraform resources. Spacelift is deployed to manage resources in my Kubernetes environment, and I have given it access to my environment where it detects configuration drift and other critical functions. I have created a workflow through which I deploy resources.
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.
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.
We use Spacelift to deploy all of our infrastructure with Terraform. It serves as a SaaS offering, allowing us to effectively manage our infrastructure deployments through the cloud version.
We used it in one of our biggest projects, Google Fiber. The client, Google, already had inbuilt data from templates, and they wanted to import everything into Spacelift to automate using the platform. So, complimentary account can be created so we can try it ourselves. It's a SaaS-based application.
The Spacelift orchestration platform combines infrastructure provisioning, configuration, and governance to increase platform team efficiency, accelerate developer velocity, and control costs. It connects to and orchestrates infrastructure as code, version control systems (VCSs), observability tools, control and governance solutions, and cloud providers to help deliver secure infrastructure faster. With Spacelift Intelligence, teams can also understand, design, deploy, and govern...
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.
I use Spacelift in my current environment for deploying Terraform resources. Spacelift is deployed to manage resources in my Kubernetes environment, and I have given it access to my environment where it detects configuration drift and other critical functions. I have created a workflow through which I deploy resources.
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.
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.
I use Spacelift to deploy my applications, particularly AWS applications and infrastructure to my personal AWS account.
We use Spacelift to deploy all of our infrastructure with Terraform. It serves as a SaaS offering, allowing us to effectively manage our infrastructure deployments through the cloud version.
We used it in one of our biggest projects, Google Fiber. The client, Google, already had inbuilt data from templates, and they wanted to import everything into Spacelift to automate using the platform. So, complimentary account can be created so we can try it ourselves. It's a SaaS-based application.