Exploring Terramate Cloud part 2 – A walkthrough

Introduction

In the first part of this two-part blog post we covered the basic setup to use Terramate Cloud. In this second part we take a closer look at the Terramate Cloud offering per se.

Let us jump right in.

Terrmate Cloud

Terramate Cloud is a SaaS offering that complements the Terramate CLI with features like monitoring of your stacks.

As we already onboarded three stacks we explore the different sections that are offered by Terramate Cloud and test the setup for configuration drifts and changes in the deployments.

Your "Homework"

The first thing you see once logged into Terramate Cloud is the “Your ‘Homework’” section that gives you a crisp overview about your setup and its state:

Usually when exploring new software, you first must get used to the wording and the semantics that the solution introduces. That should be covered in the documentation, but that also means you must switch between tabs/windows etc.

But do you see that button in the right upper corner labeled “Explain this page”? Pressing this button adds extensive in-place help and explanations to the page and its sections:

That’s cool. I really like this as it helps new joiners right in the place where they need it. Unfortunately, this is the only page where this in-place help is available.

While I do not think that this is a fitting approach for every page or detail section in Terramate Cloud, I would e.g. like to also have that in the Dashboard page. Overall a nice start.

Let’s move on to the “Dashboard” section.

Dashboard

As the name implies this page gives an overview about the metrics of your setup. Besides some KPIs about the stacks the main thing is the display of DORA metrics.

According to the pricing overview this is not included in the free edition, but I see them and I am not sad about that:

Due to the limited setup in my experiments the numbers are not impressive (though I am elite in some areas 🤪).

I think the DORA metrics part is a very valuable addition to the offering. While developing and providing business apps clearly show the impact on business, the management of infrastructure is often not seen by e.g., C-level as an essential building block for this although it is. Having these metrics in place out-of-the-box will help the teams when arguing about the importance of a decent IaC setup and of course also help the team improve. This will also have a positive impact.

The only thing that was a bit irritating about the metrics was that the preconfigured time interval points to the previous month. I would have expected that it points to the current month. Maybe looking at a “completed” month is more reasonable for overall reporting, I would always like to see the current state.

Anyway, this feature is imho a highlight of Terramate Cloud.

Resources

The next section covers the deployed “Resources”. As the name states this section provides an overview of all resources and their state:

There are tons of sorting options, so tailoring the view to your needs is possible.

However, there are some small points on the overview that came to my attention (keeping in mind that I am using a “exotic” setup on SAP BTP):

• The column “Account” is empty. I have no idea what this refers to. As there is no entry for any resource, it could also be hidden automatically by the platform. But this is not really an issue.
• The column “Name” seems to be fetched from the resource if it has a field called “name”. If there is no such field, it remains empty. Although in my case, this is most of the time empty, it is useful for me.
• The column provider triggered my inner “Monk” a bit: the first letter is capitalized, and the organization of the provider is missing. I don't know how this is derived, but I would like to see “SAP/btp” there as defined in the provider.tf file or in the Hashicorp Terraform/OpenTofu registry

From the overview, you can also dive into the details of each resource:

The details also contain the state, and I assume that sensitive data might be displayed, but I did not test that. The detailed view also provides a cross-navigation to the Terramate stack the resource belongs to.

I think this is a useful overview/detail page combination enabling you to get a quick access to the basic information of the resources that are deployed.

As we have a cross-navigation to stacks, let’s take a closer look at that section.

Stacks

The “Stacks” section provides an overview of all stacks available to Terramate Cloud:

Each line of the overview contains some basic stack information. From there you can navigate to the details screen for each stack:

Here we find more stack-related information like deployments or drift runs or policy checks (that are not available for the free edition).

From this view we can navigate to the details per resource which closes the loop to the “Resources” section.

As an intermediate summary until: nice experience, reasonable structuring of the views and detail views, the displayed information and the cross-navigation.

From the short evaluation I would say that for basic overviews my preferred areas are the Dashboard with the DORA metrics and the stacks.

Now let's evaluate the dynamical aspects of Terramate Cloud and by this investigate the remaining sections.

Handling of Configuration Drift

Let’s introduce a drift. For that I manually removed some labels on one SAP BTP subaccount and triggered the GitHub Actions workflow for drift detection (remember: no auto remediation in place).

Once the drift detection was executed, we can immediately see the effect in the “Dashboard” section namely that one stack is unhealthy due to drift:

Same is true for the “Stacks “ where we also can identify the stack that causes the issue:

This is also a scenario when the “Alerts” section comes into play:

This section informs us about the issue. As you can see in the screenshot there are also some useful predefined filters in place as buttons, I like that.

Drilling into the details of the alarm reveals the details of the drift namely the result of the planning:

This already helps a lot to pin down the issue and trigger the consequent actions if you know Terraform and the semantics of the provider that is used.

From several discussions with customers, I know that this result of the terraform plan can cause some uncertainty and questions to the fact that there are also in-place updates. They are all on computed fields and therefore not an issue, but they are often the source of confusion.

And this is where I like to see the new AI explain feature in Terramate Cloud. My opinion: one of the right spots for using AI in contrast to all the fancy marketing promises floating around at the moment.

What is even better: this feature is also available in the free plan. So let's try it out and press the “Explain drift with AI” button. This is what we get:

I like that explanation and I think this is really useful. I understand this cannot be extrapolated to complex setups/drifts.

However, imho if you are facing very complex drifts, I think you have another issue that has nothing to do with IaC: either the platform you are using per se behaves "weird" or (more often the case) your organizational setup and processes are far from where they should be when it comes to IaC and you blindly rely on “IaC will remediate things anyway”.

After fixing the drift manually and redoing the drift run via GitHub Actions, all turned green again in the Terramate Cloud cockpit. This includes the alert that gets the status „fixed“ automagically:

One thing to be aware: no matter if there is a drift or not, the GitHub Action workflow based on the template will show a successful execution. The fair assumption is that you rely on Terramate Cloud and not on monitoring the GitHub Action workflow status when it comes to drift detection, but something to be aware of.

There is one small bug I recognized in that context: if the alert is not assigned to a user and gets fixed you can no longer assign a user to it. If you try to do an assignment you get an error message/pop-up that states „Conflict“:

Small issue, but I think this should be possible even when a issue is fixed.

I did not dive into the depths of organizational workflows on how this alerting needs to be integrated into the overall organizational processes like adding an issue in GitHub or alike and referencing the alert there. I at least did not see a way to reference the alert somewhere else.

Let’s move on and make a change to the configuration via a pull request (PR).

Handling of Configuration Changes

Let us change the security setting of our subaccounts for all stacks. This is a dedicated resource, so we should see three updates of the resource, one for each stack.

I created a PR with the change which triggers the preview workflow in the repository and the PR gets synched to Terramate Cloud. As the repository is connected to Terramate Cloud via the Terramate GitHub app, the PR gets a comment of what will happen when getting applied:

The comment also contains a link to Terramate Cloud namely to the details view of the PR.

First, this connection is great (you do not need to manually navigate to Terramate Cloud) but also that it brings you to the details view. Yes, it is obvious that this is needed, but I know a lot of solutions that would bring you to the overview page and you must navigate on your own.

Let's do it the manual way and open the "Pull Request" section. We see the PR and some basic information:

At a first glance we see how many resources and stacks are affected by the change. Drilling into the details give us more information about the change of the infrastructure per stack:

Some more details including the logs are also available:

You can also display the information in an ASCII view. This might be useful when you think that there is a rendering issue, but other than that I wouldn’t know when to use this ASCII view.

As for drifts explaining the plan is a good use case for AI. This time it is not a button you need to press but a dedicated tab in the details view of the PR:

The explanation is good and contains all relevant information about the change. I like that. As for the drift this was a small change, so this feature will probably really shine in more complex update scenarios.

While I like the feature per se, I think it would make sense to integrate the AI companion or copilot or however you want to call it, consistently in the different screens.

As we are happy with the change let’s merge the PR. This results in a new deployment as we can see in the corresponding section "Deployments" in Terramate Cloud:

As in the other screens we can directly navigate to the details:

Drilling down further is possible, so that we can analyze the deployment details per stack:

Here we have the AI feature again, this time as a button. I am also not sure if it is really needed here as this change already happened and I do not see value in getting an explanation after a successful deployment. If something goes sideways, this might make more sense, but then we see an alert.

Overall, the experience in Terramate Cloud for deploying changes is also quite nice.

Wrap up

I already liked Terramate CLI and its concepts so what is my summary about Terramate Cloud?

Terramate Cloud complements that with several nice features supporting the operations namely the monitoring and troubleshooting part of IaC. The onboarding is smooth, and the experience is very good. The interplay with established GitHub flows works as expected. Function-wise the DORA dashboard as well as the alerting and PR handling look really good.

From the UI perspective I like the clean style and having the right information in the right places. Although I did not work with the tool for weeks, I enjoyed the connection between the views: depending on your way of work or the preferred view to start from I would make the bold statement that you always see the right information or can drill down/navigate to it.

Performance-wise the UI is fast as one would expect but does not always get in such solutions.

The recently added AI features are at the spots where I would expect them and where I see added value. Not overhyped, agentic, MCP, fill in the blanks BS, but fitting into the flow and nicely integrated into the UI (except for some small inconsistencies).

There are some things that I missed during my walk through:

• Storing settings and filters for views: as everybody has his own way of working and preferred setups of overviews it might be useful to be able to store some personal settings in that place. I don’t know if that’s just me being already SAP-ified to a large degree or if other see this as a useful feature, too.
• Most commonly used CI/CD pipelines are covered that I also know from customers. However, I am missing more content for Azure DevOps that I also see being used at a lot of customers. Maybe there was not yet demand for that from Terramate customers.
• After finishing my experiments, I wanted to clean up the setup on Terramate Cloud. Basically, I was looking for a “Delete/Offboard stacks” button or a CLI command like terramate rm stack xyz -- sync-deployment. I did not find something like that, so I asked on the Terramate Discord. I want to stress again, I used the free version, I am not a paying customer. But I got the answer in a few hours - highly appreciated and something I experience with every question to the Terramate team. I was right, this functionality does not exist, only archiving is possible (or asking the Terramate team to manually delete stuff). I think this would be a handy feature especially when doing proof-of-concepts on the platform.
• One more conceptual question came to my mind about best practices on how to structure Terramate Cloud organizations in combination with GitHub organizations and repositories to enable a smooth integration. I am sure there is not one perfect setup, but some guidance about the pros and cons on different ways/common scenarios would be appreciated. The “easiest” way is of course to have everything under one GitHub org, but I think then Terramate Cloud overviews become quite crowded and there are maybe other drawbacks. It would be really interesting to learn what the experiences and good practices of the Terramate team are in that area.

I think all those points are already nitpicking to some degree. Terramate Cloud is as it is already a very useful tool and complements the Terramate CLI at the right areas.

I did not wrap my head about integrating Terramate Cloud in your existing workflows, like i shortly mentioned when talking about drifts and alerts. Something that would need further investigation that I did not do, but would certainly be aprt of the evaluation when you are doing a proof-of-concept and evaluate Terramate Cloud for your organization

Long story short: If you are looking for a solution in the IaC area for making life easier in operations and monitoring Terramate Cloud is worth a closer look.