The new env zero Agent CLI is available now. Ask your coding agent about your infrastructure in plain English, and it answers from real state, inside the same roles, approvals, and audit trail your team already runs on.

Today we are launching the Agentic Experience (AX) on env zero, powered by the new env zero Agent CLI. The idea is simple. You point your coding agent, whether that is Claude Code, Cursor, Codex, or Copilot, at your env zero infrastructure, ask it a question in plain English, and it answers from your real environments, deployments, and drift instead of guessing. It is available to every account starting now.

Coding agents are already inside your workflow. They read your codebase, propose changes, and increasingly get asked to do the work rather than describe it. The open question is what they are plugged into when they try. Point one at your infrastructure today and, on most platforms, it sees a thin slice of current state, fills the gaps with guesses, and burns tokens scraping an API that was never meant for a machine to reason over. It can talk about your infrastructure. It cannot reliably operate it.

The Agent CLI changes what the agent is standing on. It gives your agent the full picture, every environment, module, template, plan, and the deployment history behind them, in a form built for a context window instead of a browser tab. Ask a question, and the agent reads real state to answer it. Ask for a change, and it acts through the same roles and approvals a person would. The commands in this post are the plumbing. The product is the conversation on top of them.

Ask your infrastructure a question

Here is what the Agentic Experience looks like in practice. Each example is a prompt an engineer types to their agent. Underneath each one is the command the agent actually runs, the receipt for what it did. You never have to type the command yourself.

"Why did payments-staging go red? Is it our change or drift?"

The agent pulls the environment's full context, its state, recent deployments, and a drift or failure summary, in a single request, then tells you whether the failure traces to your last deploy or to something that changed underneath it.

env0 context payments-staging

‍

"Before I merge this, plan the change against prod and tell me if anything gets replaced."

The agent starts an approval-gated deployment, so the plan runs but nothing applies without a human. It reads the plan, flags any resource that would be replaced rather than updated, and leaves the change waiting for your sign-off.

env0 environment deploy prod --requires-approval

‍

"Which environments in data-platform haven't deployed in 30 days, and what are they costing us?"

The agent lists every environment in the project as structured data, filters by last deployment date, and adds up the cost estimates, so you get the stale environments and their spend in one answer.

env0 environment list --project data-platform -o json

‍

"Anything waiting on my approval? Summarize what each one changes."

The agent finds the deployments paused at an approval gate, reads each plan, and gives you a one-line summary of what every pending change would do before you approve or cancel it.

env0 deployment list -o json

‍

None of these require you to know the commands, and that is the point. The Agent CLI hands the agent structured JSON on stdout, errors on stderr, and stable exit codes, so it can chain reads and actions and know exactly what happened at each step without you translating between English and the API.

Governance that already applies to agents

This is the part security teams care about, and it works today.

An agent on the Agent CLI is not a special case that sits outside your controls. It authenticates as a real env zero identity, per user through the browser or per service through an API key, never a shared token, so every read and every action is attributable to someone rather than fired anonymously.

Because your existing role-based access control applies to that identity, you decide what the agent can do simply by choosing the identity you give it. Hand it a read-scoped identity and you get an agent that can diagnose anything and change nothing. It can pull context, list environments, and read plans and logs, while deploy, destroy, and approve are not available to it at all. Give it a broader identity and the approval gates still hold. A deployment that requires approval pauses for a human no matter who or what started it, and destroying infrastructure still takes an explicit confirmation.

So the safe pattern is available now, with no new product to adopt. A read-only agent that investigates and explains, a human in the loop for anything that changes infrastructure, and a full audit trail, because the agent acted as itself and not as a key nobody can trace.

The skill is the seed of your agent operating policy

Getting an agent set up is one command.

env0 skill install

‍

‍

That writes a usage guide into your coding agent's config so it knows the exact commands, flags, and output formats for the version of the Agent CLI you have installed. It sets up Claude Code by default, with --agent cursor, --agent codex, or --agent copilot for the others.

Two things about that guide matter more than they first appear.

It is version-matched. The agent works from the command surface you actually have, not one it half-remembers from training. Invented flags are the fastest way for an agent to lose an engineer's trust on infrastructure, and a version-matched guide is how you keep them out.

And it is a file in your repository, not a hosted black box. You commit it, and you extend it. Add your own conventions on top: the golden-path templates a new environment should start from, a rule that no agent touches prod without approval, a list of projects that are off limits. Once it is committed, every agent that every engineer runs inherits the same operating manual, and it gets reviewed in a pull request like any other code. You are not just installing a skill. You are planting the seed of your team's agent operating policy, in version control, where it belongs.

Why it goes deeper than an API wrapper

A generic CLI wrapped around an API is only as good as the API underneath it. env zero already understands your environments, your modules, your deployment history, and how they connect, and the Agent CLI is built on that understanding rather than layered over it.

The clearest example is env0 context. It returns an environment's state, recent deployments, and drift or failure summary in a single call, so an agent diagnoses a broken deployment in one request instead of stitching the picture together across several. Fewer round trips, less context spent, and an answer grounded in real state.

It also clears the three obstacles we heard about from nearly every team that tried to put agent access in front of a platform. Security teams distrusted a shared, unattributable credential. One enterprise customer's security team blocked our old MCP server outright and started patching around the credential model before they ever raised it with us. Setup was a wall. As one account team put it while describing the self-hosted container, four out of five customers got stuck standing it up. And even where it worked, the surface underneath was thin, showing the latest deployment only, with no history. The Agent CLI answers all three. There is no container to stand up, a real per-identity login replaces the shared token, and the surface is deep enough that an agent never has to fall back to the raw API for context.

The old MCP server keeps working for existing integrations, but new agent capability lands in the Agent CLI now. That is where the Agentic Experience lives going forward.

What's in this release

• Point Claude Code, Cursor, Codex, or Copilot at env zero and ask about your infrastructure in plain English
• Read across environments, deployments, projects, templates, and plans, including full history
• Diagnose a failed environment (state, recent deployments, and drift) in a single env0 context call
• Run core actions when you allow it: create, deploy, destroy, approve, cancel, abort
• Scope agents with your existing roles and approvals, with every action attributable to a real identity
• See cost estimates alongside your reads
• Install a version-matched, extensible skill for your agent with one command

What comes next

Today you scope an agent by choosing the identity you give it. Next, we are making read-only the default for agents regardless of the human behind them, with write access as an explicit, audited step someone has to grant. An engineer with full permissions still gets a read-only agent unless they deliberately elevate it.

We are also expanding what an agent can see, starting with policy and governance configuration, so it can read the guardrails a project runs under and not just its deployments, and we are widening the read surface from there.

The goal has not changed. Give an agent enough real context to be useful, and never more access than it has earned.

Get started today

The env zero Agent CLI is available now. Install it with Homebrew or npm:

brew install env0/tap/env0

‍

1. Sign in with: env0 login‍
2. Run and setup your agent with: env0 skill install
3. Ask your first question

The full env zero Agent CLI documentation covers every command, flag, and output format.

Want a walkthrough? Schedule a technical demo to see the Agentic Experience in action.

FAQ

What is the env zero Agentic Experience? It is the ability to point a coding agent, such as Claude Code, Cursor, Codex, or Copilot, at your env zero infrastructure and work with it in plain English. The agent answers from your real environments, deployments, and drift, and can take action through the same roles and approvals a person would. It is powered by the new env zero Agent CLI, available now.

How is this different from the old MCP server? The MCP server needed a self-hosted container and a single shared credential, and it only ever saw the latest deployment. The Agent CLI installs directly as a single binary, authenticates per user or per service account, reads the full history and diagnosis surface, and returns structured output an agent can parse without extra tooling. The MCP server keeps working for existing integrations, but new agent capability lands in the Agent CLI.

Can I stop an agent from changing infrastructure? Yes, today. An agent authenticates as a real env zero identity and inherits that identity's role. Give it a read-scoped identity and it can diagnose but not deploy, destroy, or approve. Even with a broader identity, approval gates still pause changes for a human, and every action is recorded against the identity that ran it.

What exactly does the skill do? env0 skill install writes a version-matched usage guide into your agent's config so it knows the real commands and flags for the CLI you have installed, which keeps it from inventing them. Because the guide is a file in your repository, you can commit it and extend it with your own conventions, so every engineer's agent inherits the same rules.

What is on the roadmap? Read-only-by-default access for agents regardless of the human behind them, with an explicit, audited path to write access, broader policy and governance visibility in the CLI, and continued expansion of the read surface.

Get started: install the env zero Agent CLI or read the docs

‍

“All these investments in DevOps and developer productivity and operational efficiency are bottlenecking in these environments on security and compliance.”

This was an observation from Andrew Clay Shafer in a fireside chat with John Willis at DevOps Days Dallas 2022. One such bottleneck can come in the form of audit logs, but auditability doesn’t have to be a blocker. 

In this post we’ll take a look at why auditing is necessary for Infrastructure as Code, the benefits of having an audit trail for Terraform and other IaC frameworks (such as Terragrunt, Pulumi, CloudFormation, Kubernetes, and others), and share how you can automate your audit trail easily with env0.

How do you audit Infrastructure as Code? 

All you need is a central log management system that can aggregate and parse your audit. env zero delivers a number of benefits for auditability:

• Changes to infrastructure are tracked in the code repository, making it easy to see who made what changes and when.
• Automatically roll back changes that cause problems.
• Audit changes made by third-party vendors.

Audit log walkthrough 

There are two ways to access audit logs in env0, 1) through the UI, and 2) through the API. As always, env zero gives you the flexibility to interact with your infrastructure-as-code as it suits your organization, be it programmatically or through a simple user interface. Only an Admin user can access the Audit Logs.

The audit log contains information about who performed the activity, when the action was performed, the activity’s description, and additional data like their IP address.

The audit log shows events related to changes in your:

• Organization
• Projects
• Templates
• Environments
• Teams
• Users
• Roles
• Modules
• Git Tokens
• Cloud credentials
• API keys
• SSH keys
• Variables
• Agent configurations

Through the env zero UI

1. Go to the Organization's Settings page.
2. Click the Audit Logs tab.
3. The audit details are listed in a table.
4. Click the row's + sign to reveal additional activity details.
5. Click the Show more button at the bottom of the page to see more rows.

Through the env zero API

Use the "Fetch Audit Logs" API to retrieve your organization's audit logs programmatically. Learn more about the audit log in our documentation.

Use an audit log for governance and compliance

With this latest release, we’re continuing to deliver the enterprise-level capabilities to enable DevOps, Platform, and Infrastructure as Code teams to deliver secure software faster while ensuring compliance with internal policies or external regulations. env zero has clearly auditable versioning of infrastructure changes, giving you the answer to questions like, “What was changed, who changed it, and when was it changed?” 

We help you avoid the audit and compliance bottleneck, so you can focus on what’s important—shipping software.

In a recent blog post, I discussed expanding the idea of “Feature branches” to “Feature environments”. Using Infrastructure-as-Code, we can create an environment for every feature we are working on, thereby giving us a more flexible, isolated development environment, and allowing us to test our code early in the development process.

In this post I’d like to continue down that path, and see how we can automatically create an environment for every pull request, and gain a number of advantages over traditional static staging or qa environments.

Pull Requests & Moving Beyond Static Staging

Pull requests are a well known and common workflow step for many development teams. We usually think of them as a way you “tell others about changes you've pushed”, and where you “can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged”.

PR’s are more than just a code review - they’re a milestone in a feature’s lifecycle and a way of saying “I’m ready for this to be shared”. Beyond sharing it for feedback with the wider team, this milestone is a critical time to ensure it functions exactly as expected as part of the whole application, including any potential infrastructure or configuration changes. However - just as we wouldn’t want our data migration to run on the shared database at this point, we also want to use dedicated test infrastructure.

Static VS Dynamic PR Environments

At this point, you might ask yourself - I’m already testing my code and infrastructure changes in our dev/qa/staging environment, why complicate things?

Well, there are a number of advantages to moving from traditional, static environments, to dynamic, per-pull-request environments:

• They’re Isolated and Dedicated - having a dedicated environment for each PR means no more confusion of which version or branch is currently in staging, and no coordinating between people who want to test different versions.
• Easier To Share - Because each PR has its own fully functional environment, non technical stakeholders can provide feedback on new features very early in the process. Developers can then iterate over this feedback - without interfering with work being done by other team members.
• No Wasted Resources - Because you’re only provisioning an environment when you actually need it for testing, you’re not wasting (or paying for) resources when you don’t actually need them.
• Removes Bottlenecks In The Release Cycle - Shared development and staging environments are notorious bottlenecks for development teams, especially when they are the first place where new code meets infrastructure. It’s not uncommon to see a queue of who is using the environment for testing their features. Your developers time shouldn’t be spent on waiting.

How Do You Actually Do It?

Ok, so “per pull request environments” is an awesome idea. How are we going to actually get there? There are a number of tools out there that can help you accomplish this task but in this post, I’ll be using env0, a first of it’s kind environment-as-a-service platform - not just to deploy the environments, but to manage them as well.

Your default assumption might be to just use your CI/CD platform to set up your environment. This works, but most CI/CD platforms are built for running short lived tasks, whereas an environment’s lifecycle extends beyond deploying it once: It needs to be updated, monitored, and in the end destroyed. Besides easily automating resource provisioning using Terraform, env zero will help me keep track of which environments are up, which ones have had issues, and will provide me a top level view of how my whole team is using these environments.

Besides env0, I’ll be using Github to host my code and open pull requests, and Github Actions to trigger my environment creation. I’ll be using the same code example from the previous post, which will be deployed on AWS.

If you’d like to try this out yourself, the prerequisites for this tutorial will be

• An env zero account (it’s free, just login)
• A Github account 
• An AWS account

Getting Our Hands Dirty

Step one to fully automating anything is to make sure we can run it manually, so you’ll want to get your system set up. In my case, I’ve followed env0’s getting started guide, and taken the key steps of creating my own organization, connecting my AWS account, and creating a template for my Terraform code.

Custom workflows to the rescue

In the example code I’ve used, I also ran a bash script before deploying the environment. We can easily make sure this code runs before our Terraform is applied, using env0’s Custom Flows feature. I’ve already done this in advance and I’ve put my code in the env0.yml file, in our Github repo.

Let ‘er Rip!

We are ready to launch our first environment! Remember - this is just a manual test, to see things are ready for automation.

In the case of env0, just go to your Project Templates pages, and click “Run now” on the template we’ve created before. In the next screen, you can validate your settings, and when you’re ready - click “Run”.

‍

‍

Great!

Integrating into CI/CD

Now that we know our environment management system will properly configure our environments, we need to make it run each time we open a pull request. For that, we’ll be using Github Actions to trigger env0’s CLI.

In order to create an environment on env zero from Github Actions, we need to create an API key for env0.

Next, we’ll need to save the API key and secret as Github Secrets, in the same manner we saved our AWS credentials to env0.

The final step of connecting everything, is telling Github how to trigger our environment deploy. We’ll add the following code to our codebase, in the file `.github/workflows/pr-environments.yml`.

name: "PR Environments"
on:
 pull_request:
   types: [opened, closed, reopened, synchronize]
jobs:
 env0_pr_environment:
   name: "PR Environment"
   runs-on: ubuntu-16.04
   env:
     ACTION: deploy
   steps:
     - name: Set Action
       if: github.event.action == 'closed'
       run: echo "::set-env name=ACTION::destroy"
     - uses: actions/setup-node@v1
       with:
         node-version: '12'
     - uses: actions/checkout@v2
       with:
         repository: env0/env0-client-integrations
     - name: install
       working-directory: node
       run: yarn
     - name: deploy
       working-directory: node
       run: >
         node env0-deploy-cli.js
         --apiKey ${{ secrets.ENV0_API_KEY_ID }}
         --apiSecret ${{ secrets.ENV0_API_KEY_SECRET }}
         --action $ACTION
         --organizationId ${{ secrets.ENV0_ORG_ID }}
         --projectId ${{ secrets.ENV0_PROJECT_ID }}
         --blueprintId ${{ secrets.ENV0_BLUEPRINT_ID }}
         --environmentName "${{ github.head_ref }}"
         --revision "${{ github.head_ref }}"

In the code above, you can see we

• Determine the action depending on the Github event data
• Fetch the env zero CLI, using the `checkout` action
• Run the env zero cli to deploy, update, or destroy the environment
• The name of the environment will be the branch name

That’s all folks!

We now have a fully functioning pipeline, and our setup will automatically create a new environment for every PR we open! When we deploy a new feature, even if that feature requires new or different infrastructure, the changes in our Terraform code will automatically be reflected in the resources provisioned for the PR environment!

In the case of env0, even though environments will be automatically created and destroyed by our CI/CD integration, we can also use the env zero UI as a control plane, for understanding which environments are up, and what they consist of. You can also use env0’s cost monitoring features, to understand how much each of these environments actually costs.

‍

Thank you for taking the time to read this post, I hope it helps you setting an environment-per-PR pipeline for your team. Once you’ve tried it yourself, I’d love to hear about it! Let me know in the comments below or on Twitter at @envzero.

In this guide, we will be exploring three IaC scanning tools, Checkov, tfsec, and Terrascan. We will go into detail of each tool, as well as compare the features of all three. You can explore the other parts of this guide below.

Jump to section:

• What is Checkov?
• What is tfsec?
• What is Terrascan?
• Comparing Checkov vs. tfsec vs. Terrascan

‍

Checkov vs tfsec vs Terrascan: Which IaC Scanning Tool is the Best?

Infrastructure as Code (IaC) is a popular approach to automate the provisioning and management of cloud computing resources using declarative configuration files. However, IaC also introduces new security challenges and risks that need to be addressed before deploying to production. In this blog post, we will compare three popular IaC scan tools: Checkov, tfsec, and Terrascan. These tools can help you identify and fix security issues in your IaC code before they become vulnerabilities in your cloud environment. We will compare them based on their features, performance, usability, and compatibility with different IaC frameworks and cloud providers.

Comparing IaC Scan Tools: Video walkthrough

Our setup

Let’s take a look at our setup.

Requirements

• A GitHub account (all the hands-on sections will utilize GitHub’s Codespaces so you won’t need to install anything on your machine)

Repository

TL;DR: You can find the repo here.

What is an IaC scan tool and what is it used for?

Alright, before we dig in, let’s get an understanding of a few concepts. 

An IaC scan tool is a software application that analyzes your IaC files and detects security vulnerabilities, misconfigurations, compliance violations and other issues. IaC scan tools improve the quality and security of IaC files before they are deployed to cloud environments. These tools can help developers, DevSecOps and DevOps teams identify and fix potential problems in their code early in the development lifecycle, reducing the risk of potential data breaches, data leaks, downtime and other incidents.

What is Static Code Analysis?

Static code analysis is a method that examines the source code of a program without running it. Static code analysis tools can automate this process and detect possible errors, security vulnerabilities, and code quality issues. Static code analysis can help developers find and fix problems early in the development cycle, before they become more costly and difficult to resolve. Static code analysis can also help ensure that the code meets certain standards and guidelines, for such issues as coding style, performance, or compliance.

How does IaC scanning work?

IaC scanning works by applying a set of rules or policies to the IaC configuration files that check for common security best practices, such as encryption, authentication, authorization, logging, and monitoring. The rules or policies can be based on industry standards, such as CIS benchmarks, or customized to fit the specific needs of the organization. The IaC scanning tools can then generate a report that shows the results of the analysis, such as the number and severity of vulnerabilities found, the location of the vulnerable code, and the recommended remediation steps. The scan report itself can also be integrated with other tools, such as GitLab or GitHub, to provide feedback and guidance to developers in their workflows.

Why do you need IaC security scanning?

Imagine you are building a house and you have a blueprint that shows how everything should look and work. You wouldn't want to start construction without checking the blueprint for errors, right? You might end up with a leaky roof, a crooked wall, or faulty wiring. That's why you need IaC security scanning. It helps you find and fix any issues in your infrastructure as code before you deploy it to the cloud. It's like having a quality assurance team for your blueprint. IaC security scanning can save you time, money, and headaches in the long run.

Which IaC scanning tools exist?

Some of the most popular IaC scanning tools are checkov, tfsec, and terrascan. These tools can help you identify common vulnerabilities and best practices in your IaC code, such as Terraform, CloudFormation, Kubernetes, and more. However, they are not perfect and they may have some limitations or false positives. Here is a brief comparison of these three tools and later we will dig deeper into each one.

- Checkov: A comprehensive tool that supports Terraform, CloudFormation, Kubernetes, Helm, Serverless Framework, and more. It has a rich set of features and integrations, such as pre-commit hooks, GitHub actions, VS Code extension, etc. However, it may be slower and more complex than other tools.

- tfsec: A fast and lightweight tool that supports Terrafor. It has a simple installation process and a nice output format. However, it may not cover all the resources or scenarios that you need.

- Terrascan: A modular tool that supports Terraform, Kubernetes, Helm, Dockerfiles, and more. It has a flexible architecture that allows you to write your own policies using Open Policy Agent (OPA). However, it may have a steeper learning curve and less documentation than other tools.

As you can see, there is no one-size-fits-all solution for IaC scanning. You may need to try different tools and see which one works best for your use case. Or you may need to use a combination of tools to achieve the best results. The important thing is to scan your IaC code regularly and fix any issues that you find before they become a problem.

‍

Learn about Checkov >>

Today, we’re excited to announce that env zero is open sourcing Terratag - a CLI tool that enables users of Terraform to automatically create and maintain tagging across their entire set of AWS, Azure, and GCP resources. It enables you to easily add dynamic tags to your existing Infrastructure-as-Code and benefit from some of the cross-resource tag applications you wish you had thought of when you had just started writing your Terraform, saving you tons of time and making future updates easy.

Tagging is every cloud provider’s way of enabling you to organize and manage your cloud resources - for everything from automations to cost insights, tagging enables it all. But the actual process of tagging today is broken, requiring too much manual work with too many mistakes during it. That’s why we built Terratag to automate it all. We wanted to solve this task not just for env zero users, but for the whole developer community. Our hope is that making Terratag available for everyone will help more organizations adopt infrastructure-as-code for software development.

Why is Tagging Important?

All major cloud providers allow for tagging (or labeling) cloud resources. Moreover, they all encourage you to do so in order to benefit from their complementary services; allowing you to manage budgets, set up powerful automation algorithms, and unlock insights offered both by the cloud providers themselves, and independent third parties.

Harnessing powerful infrastructure-as-code frameworks such as Terraform to define and tag your cloud resources allows for useful dynamic tag applications on various verticals. Nevertheless, it’s important to use the right tag for the right job. Some of the most common tags include:

• Technical Tags can be used for versioning your cloud resources or specify Environment or application ID to be able to easily filter or group together resources under the umbrella of a single environment.
• Tags for Automation such as date/time tags that denote a resource should be started, stopped, deleted, or rotated.
• Business Tags can group together resources based on their business need - in a single tenant or dedicated environment it is very useful to tag a group of cloud resources with the customer ID, project, owner or cost center.

Here’s an example of how one would tag a cloud resource using Terraform:  

-resource "aws_vpc" "example" {
 # ... other configuration ...  
 tags = {    
   Name        = "MyVPC"    
   Owner       = "Operaions"            
   Environment = "${var.environment}"        
   Project     = "${var.project}"  
 }
}

Pretty powerful, yet simple, right?

And things tend to remain simple, at first.

The Problem with Tagging Today

Having only a few cloud resources makes it very easy to add both static and dynamic tags to these resources. However, as your infrastructure grows, having to repeat those same tags over and over for tens or hundreds of cloud resources can become a hassle to maintain. But that’s just the tip of the iceberg. Manual tagging processes fail on other important ways:

• Standards are hard to maintain if not enforced - Your entire team needs to be onboard and keep an eye out for newly added cloud resources, making sure they include those tags or you may miss some significant resources when acting on that metadata later.
• Harder to change - Applying changes to tag structure across the board quickly becomes a rather unmanageable task.
• Metadata can obscure what’s important - While all this tagging metadata is extremely useful for slicing and dicing later, having it everywhere on your resources is polluting your lovely IaC - making it much more verbose and harder to maintain.
• New to tagging - What if you already have plenty of Terraform modules with cloud resources which weren’t tagged to begin with? Trying to tag them all now can be painstaking work.

Infrastructure-as-code is, well, just code. And such is the case with any code - code repetition makes it harder to fix errors, apply enhancements, make adjustments and maintain readability.

Lack of proper layering or aspect control makes it harder to retrofit existing solutions.
A cross-cutting concern calls for a cross-cutting solution.

How Terratag Works

Terratag is a CLI tool allowing for tags or labels to be applied across an entire set of targeted Terraform files directory.

It generates Terraform files with your custom tags added to any GCP, AWS or Azure cloud resources:

$ terratag -dir=ops -tags={\"environment\": \"$ENVIRONMENT\",\"project\": \"$PROJECT\"}

Using Terratag as a step before terraform planning or terraform applying allows you to dynamically inject the powerful metadata of tags or labels across a set of resources - freeing you and your team from the burden of remembering to constantly apply cross-cutting tags to new resources or maintain and modify tags on existing resources.

Now you can also easily add dynamic tags to your existing IaC and benefit from some of the cross-resource tag applications you wish you had thought of when you had just started writing your Terraform code.

How do we use Terratag in env0?

env0 is a management platform that lets your team run their own cloud environments, governed by your policies and with complete visibility & cost management. 

We use Terratag to drive our Cost Management and Resource modules. We automatically inject dynamic tags for your managed Environments and Projects - allowing us to provide you with powerful insights such as viewing your entire multi-cloud cost per environment to date, over time, and much, much more.

With env0, there’s no need to deal with your own management system or build Terratag into your setup, we handle it all for you automatically.

Terratag is 100% open source

At env0, we love open source, which is why we’re making Terratag available to all.

Check out our Terratag repo on GitHub. Issues, suggestions, requests and of course, Pull Requests, are very welcome!

Web applications, Single page applications, static websites. They are everywhere. No matter if your back-end is running on Kubernetes or serverless, public cloud or on-premise, if you have a front-end, there is a good chance it is a browser rendered, statically delivered bundle of HTML, CSS and Javascript. 

In my previous blog posts, I discussed ‘Feature Environments’ and ‘Per-Pull Request Environments’. Making your entire system run such environments is no small feat, especially if you are running complex infrastructure, a very large scale system, or legacy code without IaC. But you can still make a small effort and gain a lot of value, by adapting these isolated environments for your front-end. It’s the perfect place to start, because

• Statically hosted front-ends tend to live on relatively simple and stateless infrastructure.
• Sharing a feature-in-progress on the front-end is the most interesting part of the feature to share, and non-technical stakeholders will want to see that, e.g., a Product Manager that wants to do acceptance tests. 
  

Per-pull request environments for the front-end are commonly called “Preview environments” and can be achieved in many ways. Some CI/CD providers even offer preview environments as a paid feature, but I’d like to show you how easy it is to do this on your own - using Terraform. Rolling this out on your own, will give you better control over your infrastructure, allowing you to create preview environments which are closer to your production environment, and will probably cost you less - by cutting out the middleman.

To demonstrate how, I’ll be running a simplified React app, packaged with Parcel, and using Terraform for resource provisioning, Github as a VCS, and env0 as my environment management platform. The full source code can be found here.

There are two important files we need to look at - the first one is `env0.yaml` :

version: 1
deploy:
 steps:
  terraformInit:
   before:
    - yarn 
    - yarn run build 
  terraformOutput:
   after: 
   - aws s3 sync ./dist s3://$(terraform output s3_bucket_name)

env zero will handle our Terraform files natively, taking care of creating, updating, and deleting any cloud resources we need. Before env zero initializes Terraform, we want to build our frontend. We want to do that before, so in case anything fails, we won’t provision the infrastructure for nothing.

After Terraform completes, we will run an aws CLI command, to sync our dist folder to our s3 bucket. This will upload our built website files to the bucket for hosting.

The second file we should notice is our `pr-environments.yaml`, located in the `.github` folder. It will tell Github to trigger env0, everytime we open, update, or close a Pull Request.

name: "PR Environments"
on: 
pull_request: 
 types: [opened, closed, reopened, synchronize]
jobs:
 env0_pr_environment:
  name: "PR Environment"
  runs-on: ubuntu-16.04
  container: node:12  
  steps:     
   - name: Install env zero CLI
    run: yarn global add @env0/cli     
   - name: Deploy Environment     
     if: github.event.action != 'closed'     
     run: >         
      env zero deploy   
      --apiKey ${{ secrets.ENV0_API_KEY_ID }}   
      --apiSecret ${{ secrets.ENV0_API_KEY_SECRET }}   
      --organizationId ${{ secrets.ENV0_ORG_ID }}     
      --projectId ${{ secrets.ENV0_PROJECT_ID }}     
      --blueprintId ${{ secrets.ENV0_BLUEPRINT_ID }}   
      --environmentName "${{ github.head_ref }}"  
      --revision "${{ github.head_ref }}"   
   - name: Destroy Environment   
     if: github.event.action == 'closed'   
     run: >  
      env zero destroy    
      --apiKey ${{ secrets.ENV0_API_KEY_ID }}    
      --apiSecret ${{ secrets.ENV0_API_KEY_SECRET }}   
      --organizationId ${{ secrets.ENV0_ORG_ID }}  
      --projectId ${{ secrets.ENV0_PROJECT_ID }}   
      --environmentName "${{ github.head_ref }}"

The steps here are pretty simple - we install the env zero CLI using a simple `yarn install` command, and we run the env zero CLI with the required parameters. The CLI will already know to create or update an environment based on the name, which will be the same as the branch we are working on. 

When the PR will be closed, we will run the CLI with the `destroy` command, and env zero will take care of cleaning up our cloud resources, so we can keep a clean cloud account, with low costs. 

Looking at an open Pull Request, Github informs us that it ran the deployment successfully - 

‍

Looking at env0, we can see a list of all our PR environments, and for each one, we can use the “Outputs” section, to get the environment’s website URL - 

That way I can Slack my product manager, and let them know they can already play around with the new video feature we’ve been working on, so I can get feedback early!

Advanced Environment Management‍

Using env zero for managing preview environments opens up some new options that are only available on an advanced environment-as-a-service platform such as env0. To name a few:

• Time To Live for environments - making sure I don’t have any leftover resources.
• Detailed cost monitoring - getting actual costs per environment is a huge help in understanding where our cloud costs come from.
• Role based access - anyone in the organization can access env0, and I know they won’t do any damage, when they are assigned the correct role. 

Thank you for taking the time to read this post, I hope it helps you setting up preview environments for your web application. Once you’ve tried it yourself, I’d love to hear about it! Let me know on Twitter at @envzero.