When it comes to infrastructure as code (IaC), solutions like OpenTofu has long been the go-to solution for many organizations. Its ability to declare, provision, and manage resources in a consistent, repeatable way has revolutionized how we think about infrastructure management.

While the command line tool is great for running your own automations to set up environments on a single laptop, try to scale that across a whole organization, and it gets messy. Enterprise orgs need a centralized workflow for managing deployment through their IaC platform, and engineers need a lightweight and simple method of accessing it.

This is where frontends become critically important. A good frontend can lower the barrier to entry, streamline processes, reduce errors, and ensure that your entire team (not just the DevOps gurus) can access the infrastructure their projects need on demand. 

But frontends aren’t created equal, and all of the major ways people build them today introduce their own issues. Today we’re going to look at how to use Tempest as an interface into IaC like OpenTofu, and why our innovative approach to IaC makes it easier to implement, easier to use, and easier to scale than ever before. 

Common Approaches to Building a OpenTofu Frontend

But first, when we talk about IaC frontends, what are we actually talking about? There are three major ways that people build interfaces into OpenTofu:

1. Atlantis

Atlantis is a popular open-source tool that provides a self-hosted platform for OpenTofu automation. It integrates with GitHub, GitLab, and Bitbucket to automatically run tofu plan and tofu apply in response to pull requests. Effectively, Github becomes the frontend for all your infrastructure. Engineers interact with it through the familiar pattern of opening pull requests and having them approved. 

• Pros: Atlantis offers a straightforward, chatops-style approach to reviewing OpenTofu changes. Engineers can comment on a pull request and let Atlantis handle the grunt work of checking and applying infrastructure changes. It also elegantly handles some of the credentialing, concurrency, and audit trail problems that are presented by other options.

• Cons: This ties your infrastructure indelibly to Github, with all that implies. Unless you have a self-hosted Git instance, it’ll require some publicly available resource, which increases your threat surface in ways that some organizations will find unacceptable. Although working with Git will undoubtedly feel familiar to your product teams, this approach exposes the full complexity of your configuration files, which probably won’t. In a large and diverse org with teams that have varying levels of familiarity with infrastructure code, this introduces a big potential for user error and will probably require a fair amount of DevOps hand-holding. Finally, you’ll have to self-host and maintain Atlantis.  

2. Custom HTML Forms

Another approach is to create rudimentary HTML forms that capture user inputs, such as resource names, regions, or instance sizes. On the backend, a script transforms these inputs into OpenTofu variables, updates your .tf files, and initiates a tofu plan/tofu apply.

• Pros: This can be fairly simple to implement if you already have a small engineering team capable of building web interfaces and hooking into OpenTofu’s CLI. It’s probably the lowest lift self-serve option if you only have to worry about a few simple configurations that don’t change much from build to build. 

• Cons: Building forms in and of itself is simple—but a good IaC frontend is more than just the form itself, and the bits around that are much harder to implement. As your infrastructure grows, these forms quickly become unmanageable. You’ll need to update the forms every time your OpenTofu modules or logic changes. You also have to handle hosting, authentication, and integrate logs to maintain accountability and audit trails. Most teams will find they’ve already outgrown this approach by the time they reach the size that IaC really starts to show its worth. 

3. Automated Form Builders (JSON Forms, react-jsonschema-form, etc.)

Automated form builders or low-code platforms can interpret JSON or YAML schemas to generate user-friendly forms. This often sounds like the perfect solution: automatically generate forms so you don’t have to build each one manually.

• Pros: Offers the same simplicity of building your own forms for teams with too  

• Cons: The forms can still expose too much complexity from your OpenTofu configurations. If your module has 30 variables, the generated form might have 30 fields, many of which might be irrelevant to most users. This can lead to confusion and errors. Furthermore, you still have to tackle the complexities of version control, plan approvals, and a central auditing system.

As you can probably tell, these approaches share a common set of shortcomings:

1. Usually Need to Self-Host
   Atlantis and many other solutions require you to run them in your own environment, which adds overhead for provisioning, updates, and maintenance. If you’re trying to reduce your operational load, this can negate the convenience factor of a frontend.

2. Naive GitHub Pull Request-Based UX
   Even if you integrate with GitHub, the user experience frequently devolves into “copy this code snippet, paste it into a YAML file, open a pull request, wait for approval.” For many non-technical stakeholders, this is daunting. It also leaves plenty of room for user error, even with standard templates and the extra guardrail of manual code review. 

3. Requires Dedicated DevOps Approval
   When everything hinges on a pull request, you effectively create a bottleneck at the DevOps team or repository maintainers. They’re the gatekeepers who must review and approve every infrastructure change. This is great for safety but limits the ability of self-serve to deliver the efficiency most teams are looking for when they implement it. In large organizations, a single team might manage hundreds of such requests daily.

4. High Cognitive Load for Engineering Orgs
   Some teams might be comfortable with OpenTofu, while others have never touched it. Requiring everyone to understand .tf or .yaml basics is a tall order. People are often scared to make pull requests against YAML files they don’t fully understand, so they either avoid them or submit changes with minimal confidence. With automated form builders, often every possible variable is exposed as a field, creating an unwieldy and unusable form. 

5. Difficult to Custom Build Enough Forms for Every Automation
   If your approach is to build custom HTML forms for each new resource or module, you’ll likely spend more time building forms than on actual infrastructure logic. This overhead grows in tandem with the number of services and resources you manage.

6. Credentialing, Logging, and Accountability
   Handling credentials in a distributed system of custom forms or Git workflows can be tricky. Where do you store secrets? How do you enforce roles and access control? Proper logging and auditing for governance or compliance can be cumbersome with homegrown solutions.

7. Shadow IT and Lack of Transparency
   With a self-serve platform that doesn’t provide robust governance, you run the risk of teams spinning up resources under the radar. Over time, you might discover unmonitored or under-managed infrastructure. These “shadow IT” components are difficult to track, secure, and decommission.

Enter Tempest: A Better IaC Frontend

Tempest is a full developer platform on its own, so you can actually use it out of the box to create elegant self-serve workflows for most infrastructure tasks with no outside infrastructure code required. But it can also be used on top of your existing library of automations to effortlessly create the same self-serve experience for OpenTofu, with native logging, audit trails, and credential management as an added bonus.

Tempest offers all of the benefits of other approaches, with few of the drawbacks:

1. Simple Integration
   Tempest can tie into your existing OpenTofu workflows with minimal fuss. You don’t have to rip out your existing setup, just augment it with a more user-friendly front layer.

2. Clear, Consistent UX with Minimal Cognitive Load
   Instead of requiring every user to be a OpenTofu expert, Tempest provides a curated interface. Users see only the parameters you need them to see—no more, no less. Most use cases can be accomplished with as few as two fields, with all of the complexity happening on the backend. That reduces the chance of mistakes and alleviates the intimidation factor.

3. Centralized Credentials, Logging, and Hosting
   Because Tempest acts as the interface layer, it can maintain a central store for secrets and credentials. You no longer need to worry if each HTML form or integration is storing keys improperly. Tempest also automatically logs actions for accountability, so you can track who made which request and when.

4. Infinitely Extensible
   Tempest isn’t limited to just OpenTofu. You can mix OpenTofu and non-OpenTofu code within the same environment. This is valuable when your deployment pipelines incorporate scripts, configuration management, or other custom tools. By standardizing on Tempest’s UI, you avoid having to build multiple separate frontends.

5. A Single, Consistent Interface for All Types of Infrastructure
   If your organization is building custom microservices or using specialized frameworks, you can incorporate them seamlessly into Tempest. For instance, you might have a custom application for managing certain network policies, while the rest of your infrastructure is under OpenTofu. With Tempest, both can be accessed from a single, coherent interface.

6. Robust Logging and Accountability
   Every resource creation or update performed through Tempest is tracked. This includes user authentication details, timestamps, resource identifiers, and plan/apply logs. If an audit or compliance check is needed, you can easily pull up records from a single, centralized dashboard.

How Tempest Private Apps Work with OpenTofu

Check out this video walkthrough for a step-by-step on leveraging Tempest with OpenTofu.

First, you’ll build a Private App in Tempest that references your existing OpenTofu scripts. For example, let’s say you have an OpenTofu file for provisioning AWS S3 buckets. To add that to Tempest, you would create a new Private App in the Tempest interface, give it a name.

Next, you use the Tempest CLI to initialize a new app, using the tempest app init command, which will automatically scaffolds a sample Hello World app. You simply need to replace the example code with your existing OpenTofu code—Tempest runs it and handles input and output natively, so there’s never any need to reformat or rewrite anything. 

To make it useable, you’ll simply have to define an input schema for your app in a json file. We’ve got a few examples of what this ends up looking like up on in the Examples section of our Github page. You can either build this yourself, or use our App Playground to create one using a visual interface to preview what end users will see. Tempest gives you the flexibility to expose only those fields that need user input, eliminating the need for long and confusing forms.   

At this point, the app is basically ready to go. You can see what actions it supports by using the tempest app describe command, or and test that it works using the tempest app test command in the CLI. 

Once you’re satisfied that it’s working as intended, you create a new version of the app in the Tempest web console—built-in versioning helps you to continuously update and improve your private apps, without worrying about breaking existing recipes that use them. Then you connect to it using the Tempest CLI and your API key, and run the tempest app serve command, and set it to publish in Tempest.

This creates a new app in Tempest that can be used in any recipe. Private apps are treated exactly the same as first party apps created by Tempest, so there’s no need to worry about whether the underlying code is an OpenTofu configuration or a Tempest-specific automation—everything just works. 

Want to share these capabilities across multiple workflows? Simply build a recipe that references your Private App. Under the hood, your original scripts will be executed with all the guardrails Tempest provides—logging, auditing, credential management, and more.

In other words, Tempest becomes a friendly front-end for your IaC, letting you harness the full power of OpenTofu with minimal friction, zero guesswork, and no need for major re-architecting.

Wrapping up

OpenTofu is a game-changer for infrastructure management, but as teams scale, these tools can get unwieldy. Options like Atlantis, DIY HTML forms, or auto-generated forms can help, but each comes with its own headaches—from self-hosting overhead to intimidating pull requests against complicated files.

That’s where Tempest shines. It creates a self-service, centralized platform for infrastructure provisioning, sparing less technical users from OpenTofu’s complexity. At the same time, it covers governance, logging, and security right out of the box. Plus, Tempest is extensible—you can combine OpenTofu code with other scripts in a single environment, which is a huge win for large or fast-growing orgs.

The right frontend isn’t just a flashy UI; it’s a strategic move that reshapes how your team builds, collaborates, and scales. Whether you’re working with a small set of resources or navigating a massive multi-cloud strategy, Tempest helps everyone—from DevOps engineers to product teams—move away from complicated DIY workflows and into a streamlined, confident way of managing infrastructure.