Exploring Terramate Cloud part 1 – Getting things set up

Introduction

Exploring Terramate Cloud was on my to do list for a while now. The latest updates of Terramate Cloud about DORA metrics and integration of some AI explain features reminded me of that. A good time to get this thing done.

This …


This content originally appeared on DEV Community and was authored by Christian Lechner

Introduction

Exploring Terramate Cloud was on my to do list for a while now. The latest updates of Terramate Cloud about DORA metrics and integration of some AI explain features reminded me of that. A good time to get this thing done.

This is a two parted blog post. The first part you are currently reading is about getting the basic setup for using Terramate Cloud in place. The second part is about how Terramate Cloud itself and what it brings to the table.

Context

I have already written some blog posts about the Terramate CLI and how it can support you with challenges in your day-to-day work with Infrastructure as Code (IaC), in my case Terraform/OpenTofu.

The CLI is open source and free of charge. In my opinion it is a very useful tool with some smart concepts and can help you with some challenges around setup of infrastructure especially on SAP BTP. If you are interested in those blog posts, here they are:

But there is also a SaaS offering of Terramate, namely Terramate Cloud. This offering focuses on the management and observability part of IaC.

There is a free plan for Terramate Cloud which reduces the barrier of trying it out to zero.

Prerequisites

The basic prerequisite is to have a IaC setup in place that consists of Terramate stacks. I created such a setup and you can find it on GitHub: https://github.com/btp-automation-scenarios/btp-terramate-cloud.

It comprises three stacks (dev, test and prod) with a basic setup on SAP BTP. I used the Terramate code generation feature, but that is not needed to use Terramate Cloud. The only prerequisite is to have Terramate stacks in place.

I deployed the stacks from my local machine via the Terramate CLI. My remote state storage is an Azure Blob Storage, but that has no impact on Terramate Cloud.

On the Terramate Cloud side we first need to sign up to Terramate Cloud and create an organization that is used to connect your deployments to Terramate Cloud. No credit card required, which I highly appreciate when trying things out.

With these two things in place we must make Terramate Cloud aware of our deployed stacks. The onboarding process is very well described in the documentation and consists of three steps:

That’s it. Now the stacks are onboarded to Terramate Cloud.

As we also want to monitor our stacks, we need to define CI/CD workflows to keep Terramate Cloud informed about changes but also get information back e.g, in the case of pull requests.

As my code is on GitHub, I made the necessary configuration to give Terramate access to my GitHub repository. This comprises the enabling of OIDC and adding a Terramate GitHub app to my GitHub repository. While I did that on repository level, you can also do that on GitHub organization level.

To have an interaction with Terramate I added three workflows to my repository:

  • A workflow for the deployment of the stacks after a PR got merged
  • A workflow for drift detection
  • A workflow for executing a preliminary planning of changes that gets triggered whenever a pull request is opened.

Setting up the workflows is also quite easy as the Terramate documentation provides templates for the three workflows:

The only adjustment I made was that I removed the automatic remediation of the drift in the drift detection workflow.

Taking a closer look at the workflow code, you will see that the change detection of Terramate CLI comes into play (no we do not use -X) as well as some Terramate Cloud specific options that are responsible for the synchronization:

Terramate CLI options for Cloud sync

There was only one thing I struggled with when using the proposed actions namely the conditional check for changes in the stacks. This is used to execute the action only if there have been changes in the stacks which is proposed like this:

- name: List changed stacks
        id: list
        run: terramate list –changed

The condition for consequnt steps is defined as

  if: steps.list.outputs.stdout

This did not work for me, and I also did not find stdout as a default output for a GitHub Actions workflow step. Maybe I missed something or I made a typo I could not identify, but to get things working I replaced the proposed code with the following code:

- name: List changed stacks
        id: list
        run: |
          terramate list --changed > changed-stacks.txt
          echo "CHANGEDSTACKS=$(awk 'END { print NR }' changed-stacks.txt)" >> $GITHUB_OUTPUT
          rm -rf changed-stacks.txt 

Not elegant, but pushing the terramate list command output directly to the GitHUb output gave me some errors in the consequent execution.

The condition then reads:

if: steps.list.outputs.CHANGEDSTACKS > 0

And with that our setup is ready for exploring Terramate Cloud.

Overall, the onboarding experience is straightforward and there is no obstacle to try this offering out, at least none that I came across. The documentation is helpful especially when it comes to the templates for the pipelines which are a huge time saver. By the way: these templates also exist for GitLab and Bitbucket.

This onboarding experience raised the barrier quite a lot, let’s see if Terramate Cloud per se can keep up with it in the next blog post Exploring Terramate Cloud part 2 – A walkthrough.


This content originally appeared on DEV Community and was authored by Christian Lechner


Print Share Comment Cite Upload Translate Updates
APA

Christian Lechner | Sciencx (2025-07-30T05:39:39+00:00) Exploring Terramate Cloud part 1 – Getting things set up. Retrieved from https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/

MLA
" » Exploring Terramate Cloud part 1 – Getting things set up." Christian Lechner | Sciencx - Wednesday July 30, 2025, https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/
HARVARD
Christian Lechner | Sciencx Wednesday July 30, 2025 » Exploring Terramate Cloud part 1 – Getting things set up., viewed ,<https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/>
VANCOUVER
Christian Lechner | Sciencx - » Exploring Terramate Cloud part 1 – Getting things set up. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/
CHICAGO
" » Exploring Terramate Cloud part 1 – Getting things set up." Christian Lechner | Sciencx - Accessed . https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/
IEEE
" » Exploring Terramate Cloud part 1 – Getting things set up." Christian Lechner | Sciencx [Online]. Available: https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/. [Accessed: ]
rf:citation
» Exploring Terramate Cloud part 1 – Getting things set up | Christian Lechner | Sciencx | https://www.scien.cx/2025/07/30/exploring-terramate-cloud-part-1-getting-things-set-up/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.