Terraform Bulk Import: Finding Unmanaged Resources at Scale

We've already covered the mechanics of a single terraform import run, and separately looked at bulk import strategies like scripting and environment scans for larger batches. Both hold up fine once you already know which resources you're targeting. What neither one solves is the step before that: at the scale most brownfield environments actually present, the honest answer to “which resources need importing” is “we don't know, we inherited this.”

This piece picks up that specific problem: finding hundreds of unmanaged resources across accounts and clouds, deciding which ones matter first, and bringing them under management without turning the whole exercise into a six-month side project. That covers Terraform's own new bulk-discovery workflow, where it stops being enough on its own, and how CloudQuery and env zero's Cloud Compass close the gap between finding something and actually governing it.

Why single-resource import doesn't scale

terraform import and the declarative import block both assume you already know what you're importing: a resource address, a provider-specific ID, a resource block waiting to receive it. That's a reasonable assumption for one EC2 instance or one S3 bucket. It stops being reasonable once you're looking at an account that predates your IaC adoption by several years, or one that arrived through an acquisition with no documentation at all.

The actual bottleneck at that scale usually isn't the import command. It's discovery: knowing which resources exist, which of them are already managed somewhere, and which ones carry enough risk (an IAM role, a public S3 bucket, a security group with an open ingress rule) that they should jump the queue. Guessing your way through that with console tabs open across three accounts doesn't scale any better than running terraform import by hand for every resource does.

Terraform's native answer: list blocks and terraform query

Terraform 1.14, generally available since November 2025, shipped a native answer to part of this problem. A new .tfquery.hcl file type holds list blocks that query your provider for resources matching a filter, and the CLI gained a companion terraform query command to run those queries and, optionally, generate importable configuration from whatever it finds. Requirement-wise, resource-identity-based search needs Terraform 1.12 or newer, with the full workflow reaching general availability in 1.14.

A query file looks like this:

# find-unmanaged.tfquery.hcl
list "aws_instance" "unmanaged" {
  provider = aws
  limit    = 50

  config {
    region = "us-east-2"
    filter {
      name   = "tag:ManagedBy"
      values = ["unmanaged"]
    }
    filter {
      name   = "instance-state-name"
      values = ["running"]
    }
  }
}

Run terraform query and Terraform prints what it found, each result labeled with its list.. reference and resource identity. Add the -generate-config-out flag and it writes matching resource and import blocks, identity included, to a file you review and copy into your configuration before running terraform apply:

$ terraform query -generate-config-out=generated.tf

list.aws_instance.unmanaged: 12 results found
Generated configuration written to generated.tf

That's a real improvement over writing a dozen import blocks by hand, and it's worth knowing on its own merits. Two limits are worth flagging before you plan around it, though. First, list support has to exist for the specific resource type in that specific provider, so coverage varies and you should check your provider's documentation rather than assume it. Second, the polished side-by-side review experience (comparing what the query found against what's already tracked elsewhere) lives in the HCP Terraform UI and needs the cloud block configured to connect. Running terraform query itself doesn't require HCP Terraform, but the discovery it does is scoped to one provider configuration at a time.

Where native search runs out of room

For a single AWS account and a resource type your provider already supports, native query blocks are the right tool and probably the only one you need. The gap shows up at the scale that actually produces years of undocumented ClickOps: multiple clouds, SaaS platforms and identity providers alongside them, and a need to ask questions that don't map cleanly onto one provider's filter syntax, like “which storage resources across every cloud we run have no Terraform-managed tag at all.” A list block answers questions about one resource type in one provider. It doesn't give you a single place to ask that question once and get an answer back.

CloudQuery: one inventory across everything, not just what a single provider's list block supports

This is the problem CloudQuery, which merged with env zero in 2026, was built to solve before Terraform's own query workflow existed. CloudQuery syncs resource data from over 70 sources, cloud providers, GitHub, Okta, and more, into a single normalized, SQL-queryable layer. Every synced resource lands in a unified Asset Inventory with consistent schemas across providers, full-text search, and filters you can save and share. For anything a saved filter can't express (joins across resource types, aggregations, multi-condition logic) the SQL Console runs queries directly against the same data.

That matters for a question people actually ask, in one form or another, constantly: which resources across the whole environment have no tags at all, broken out by type? A resource nobody bothered to tag is usually a resource no pipeline, Terraform included, ever touched, which makes it a decent starting signal for “probably unmanaged.” Answering that by hand means maintaining a list of which of AWS's roughly 330 resource types actually support tags (the unified tagging API only covers about 140 of them), calling the rest through separate per-service APIs, and remembering that things like IAM role policies have to be excluded entirely since they're inline JSON attached to a role rather than a taggable resource in their own right. None of that per-service, per-account legwork exists once everything is already sitting in one normalized inventory. The sketch below isn't a documented CloudQuery query, table and column names depend on which sources you've synced and how, but it shows the shape of the question:

-- Illustrative shape only, not a documented CloudQuery query.
-- Substitute your actual synced table and column names.
select cloud, resource_type, count(*) as untagged_count
from 
where (tags is null or length(tags) = 0)
  and resource_type != 'aws_iam_role_policy'
group by cloud, resource_type
order by untagged_count desc;

For the real schema and supported query patterns, CloudQuery's SQL Console documentation is the source of record. The point holding up here isn't the exact syntax, it's that one query, run once, covers every connected cloud and account, where the manual version means hand-maintaining a taggable-type list and calling a different API per service, and a single list block still only covers one resource type in one provider.

From discovery to governed import with env zero

Finding a resource and safely bringing it under management are two different problems, and the second one is where env zero's own Cloud Compass comes in. Cloud Compass scans your connected cloud accounts, categorizes each resource by how it's actually been touched (ClickOps console changes, API or CLI calls, IaC operations) and scores each one on a severity scale that weighs both the mix of those operation types and how sensitive the service itself is. IAM, KMS, and EC2 carry more weight than a low-traffic S3 bucket, for the same reason a security team would care more about one than the other.

Select a resource in Cloud Compass and generate IaC code for it directly, Terraform or OpenTofu, ready to review and commit. Whether a given resource's config comes from Cloud Compass, from terraform query -generate-config-out, or from CloudQuery's inventory data feeding a hand-written import block, the resource lands in env zero the same way anything else does: through a normal PR-based plan. OPA policies evaluate the newly imported resource before it merges, the standard approval gates apply, and once it's in, drift detection owns it going forward the same as infrastructure env zero provisioned from scratch.

That's the practical version of the two companies' post-merger story: CloudQuery finds what exists across your entire environment, not just what one Terraform provider's list block happens to cover, and env zero is where that discovery turns into something governed rather than a one-time cleanup that drifts right back into ClickOps six months later.

A practical workflow for bulk import

1. Inventory everything first. Run a CloudQuery sync across your connected accounts and integrations before importing anything. You want the full picture, not just the corner of it one provider's query supports.
2. Prioritize by risk, not by convenience. Cloud Compass's severity scoring, or a manual pass weighting IAM, networking, and data stores above everything else, tells you which unmanaged resources represent real exposure versus which ones can wait.
3. Generate configuration, don't hand-write hundreds of resource blocks. Use Cloud Compass's generate-code action, terraform query -generate-config-out for resource types it supports, or both, depending on where a given resource showed up.
4. Land it through a normal PR. Import in batches small enough to review, not one sweeping commit. Each batch gets a plan, a policy check, and an approval, the same as any other change.
5. Re-run discovery and confirm. After each batch, check that the imported resources actually show up as IaC-managed rather than assuming the import succeeded because the apply didn't error.

Does OpenTofu support the same bulk query workflow?

Not yet, and this is one of the few places in this series where Terraform and OpenTofu genuinely diverge rather than matching each other feature for feature. an open feature request on OpenTofu's repository asks for a tofu query command and provider list resource support mirroring Terraform 1.14, and as of this writing it's still open. OpenTofu does support for_each on import blocks since version 1.7, which lets you bulk-import many resources of the same type through a single block once you already know their identifiers, the same for_each pattern that applies to resource and module blocks generally. What it doesn't yet have is the discovery half: a native way to ask a provider which resources exist that aren't in state yet. If you're on OpenTofu today, that gap is exactly where CloudQuery's provider-agnostic inventory carries more of the weight, since it doesn't depend on which engine eventually ships native query support.

Best practices for bulk import at scale

• Prioritize by service sensitivity first. An unmanaged IAM role or security group is worth importing before an unmanaged low-traffic storage bucket, regardless of which one your tooling happened to surface first.
• Import in reviewable batches. A single pull request with 200 new resource blocks defeats the purpose of routing imports through policy and approval in the first place.
• Pin provider versions across a batch. Resources imported under different provider versions can produce inconsistent generated configuration for the same resource type.
• Prefer import blocks over one-off CLI commands for anything beyond a handful of resources, so the batch is reviewable as a diff rather than a sequence of commands someone ran locally.
• Treat discovery as recurring, not a one-time project. Re-sync and re-scan on a schedule. New ClickOps resources accumulate the same way the original backlog did.

Frequently asked questions

Q. What's the difference between a single terraform import and bulk import?

A single import (terraform import or one import block) assumes you already know the resource address and provider ID you're targeting. Bulk import adds a discovery step in front of that, finding which resources exist and aren't yet managed, before any importing happens.

Q. Does terraform query require an HCP Terraform account?

No. terraform query runs from the Terraform CLI against your configured provider without needing HCP Terraform. HCP Terraform adds an optional UI for comparing query results against what's already tracked across your workspaces, but the underlying query and generate-config workflow works standalone.

Q. What is CloudQuery and how does it relate to env zero?

CloudQuery is a cloud asset inventory platform that syncs resource data from cloud providers and SaaS integrations into a single, SQL-queryable layer. env zero and CloudQuery merged in 2026, combining CloudQuery's discovery and inventory capabilities with env zero's IaC orchestration and governance.

Q. Should I use CloudQuery or Cloud Compass to find unmanaged resources?

They're complementary rather than competing. CloudQuery gives you a broad, cross-cloud, cross-integration inventory you can query with SQL. Cloud Compass builds on that with severity scoring specific to IaC coverage and a direct action to generate Terraform or OpenTofu code for a selected resource, inside the env zero workflow.

Q. Does OpenTofu support terraform query or list blocks?

Not currently. There's an open feature request on OpenTofu's GitHub repository asking for parity, but as of this writing OpenTofu's bulk-import story is for_each on import blocks (available since version 1.7), which simplifies importing many resources once you know their identifiers without adding a native discovery mechanism.

Q. How should I prioritize hundreds of unmanaged resources?

Weigh both the type of resource and how it's been touched. Services like IAM, KMS, and networking carry more risk than low-traffic storage or compute, and resources with a history of manual console changes carry more risk than ones only touched by scripts or existing IaC. Import the highest-risk combination first.

Key points

Single-resource import workflows, whether the CLI command or the declarative block, assume you already know what needs importing. At scale, that assumption is the actual bottleneck. Terraform's own terraform query workflow helps within a single provider's supported resource types. Beyond that, a provider-agnostic inventory like CloudQuery answers the broader question of what exists across your entire environment, and env zero's Cloud Compass turns that discovery into reviewed, policy-checked infrastructure rather than a spreadsheet that goes stale the day after you finish it.

You run [.code]terraform apply[.code], it fails partway through, and the next command you run refuses to move: [.code]Error acquiring the state lock[.code]. Nothing is broken yet, but nothing will proceed either until the lock is cleared.

This guide covers what [.code]force-unlock[.code] actually does, when it is safe to use, how to find the lock ID on every major backend, and what to do if the command itself does not fix things.

What does terraform force-unlock do?

Terraform locks state before any operation that could write to it. The lock stops two processes from writing to the same state file at once, which is the most common way a state file gets corrupted. Locking happens automatically and silently on every plan and apply where the backend supports it. You will not see a message unless acquiring the lock takes longer than expected.

[.code]force-unlock[.code] is the manual override for when that automatic process gets stuck. It removes the lock record so a new operation can proceed. According to HashiCorp, the command does not modify your infrastructure, and on most backends it does not touch your state data either. It just clears the record that says the state is currently held.

Usage:

terraform force-unlock [options] LOCK_ID

The only option is [.code]-force[.code], which skips the yes or no confirmation prompt. That is useful inside a script or CI job where nothing is available to type “yes” into. Otherwise leave it off, since the confirmation step is the last chance to catch a mistake before you unlock something someone else is actively using.

The lock ID is not optional and is not guessable. Terraform prints it in the error message when a lock is already held, and [.code]force-unlock[.code] requires an exact match. Per HashiCorp's own documentation, the ID works as a nonce, a one-time verification token that ensures a lock and an unlock target the same lock. That is deliberate: you can only release a lock you can identify, not just any lock on the state file.

One thing worth flagging up front: on the local backend, a stuck lock can only be cleared by the same machine and user that created it. There is no separate process to force it from elsewhere, which is one more reason most teams move to a remote backend, such as the ones covered in this backend configuration guide, before this becomes a live problem.

When should you use the force-unlock command?

Treat [.code]force-unlock[.code] as a last resort, not a first response. If two operations are genuinely running against the same state at the same time, forcing a lock open defeats the entire purpose of state locking and can leave you with a corrupted state file. Only run it when you are certain the process that created the lock is no longer active.

A stuck lock usually traces back to one of a few causes:

• A [.code]terraform apply[.code] or [.code]plan[.code] was cancelled or errored mid-run, for example because a CI job timed out or someone hit Ctrl+C, so Terraform never reached the step where it releases the lock.
• The machine or build agent running Terraform lost its network connection to the backend before the lock could be released.
• The backend storage itself changed mid-operation, for example a Terraform run modifying firewall rules, private endpoints, or access policies on the very storage account that holds the state file.

If none of those match your situation and you are not sure why the lock exists, treat that as a reason to investigate before clearing it, not a reason to assume it is safe to force.

Where to find the lock ID for every backend

In most cases you will not need to go looking. The lock ID appears directly in the [.code]Error acquiring the state lock[.code] message, under the [.code]ID:[.code] field, alongside who holds it and when it was created. The backend-specific detail below matters mainly when you are troubleshooting secondhand, for example clearing a lock a teammate reported without a fresh error message in front of you.

Local backend

Terraform writes a [.code].terraform.tfstate.lock.info[.code] file next to the state file while an operation is in progress. It is a small JSON object containing the lock [.code]ID[.code], the operation type, and who created it. On clean exit, Terraform deletes this file automatically. As noted above, a lock created by one machine cannot be released by [.code]force-unlock[.code] from a different one.

Amazon S3

As of Terraform 1.11, the S3 backend supports native state locking through the [.code]use_lockfile[.code] argument, and no longer requires a separate DynamoDB table. Setting it to [.code]true[.code] tells Terraform to create a lock object in the same S3 bucket as your state, using conditional writes so only one process can create it at a time.

terraform {
  backend "s3" {
    bucket       = "mybucket"
    key          = "path/to/my/key"
    region       = "us-east-1"
    use_lockfile = true
  }
}

With native locking, the lock ID is whatever the error message reports; there is no separate table to query. If your configuration still uses the older [.code]dynamodb_table[.code] argument, note that HashiCorp has deprecated it in favor of [.code]use_lockfile[.code]. On that legacy path, the lock lives as an item in the DynamoDB table, keyed by a partition key named [.code]LockID[.code], and you can inspect it directly:

aws dynamodb get-item \
  --table-name your-lock-table \
  --key '{"LockID": {"S": "your-bucket/path/to/terraform.tfstate"}}'

Azure Blob Storage

Azure Blob Storage implements locking through native blob leases, with no extra backend configuration required. If a run is interrupted mid-apply, the lease can be left in place. The lock ID appears in the error message, but you can also inspect the lease state directly:

az storage blob show \
  --account-name YOUR_STORAGE_ACCOUNT \
  --container-name YOUR_CONTAINER \
  --name path/to/terraform.tfstate \
  --query 'properties.lease'

If [.code]force-unlock[.code] is not an option, for example the lock ID is unavailable, you can break the lease directly through the Azure CLI, which achieves the same result at the storage layer:

az storage blob lease break \
  --account-name YOUR_STORAGE_ACCOUNT \
  --container-name YOUR_CONTAINER \
  --blob-name path/to/terraform.tfstate

Google Cloud Storage

The GCS backend also locks natively with zero extra configuration. Terraform writes a lock object at [.code]/.tflock[.code] in the same bucket as your state, and the lock ID is the object's generation number, which is included in the error message. Deleting that object directly is the manual equivalent of [.code]force-unlock[.code] if the CLI command fails for some reason.

HCP Terraform and Terraform Enterprise

This is a common point of confusion: [.code]terraform force-unlock[.code] is a CLI command that works against backends where Terraform itself manages the lock file. HCP Terraform and Terraform Enterprise instead lock and unlock workspaces through their own UI and API, not the CLI command. In the workspace's Actions menu, you can select Lock workspace or Unlock workspace directly, or call the workspaces API endpoint to do the same thing from automation.

Consul

With the Consul backend, lock information lives in the Consul key-value store rather than in a file. You can list it with the [.code]consul kv get [.code] command, or query the same data through Consul's HTTP API.

Using terraform force-unlock: a worked example

1. Identify the lock ID from the error message. For example: [.code]Lock Info: ID: b8814894-4a5f-217b-e97b-c4f5c02a1f88[.code].
2. Confirm nobody else is running an operation against this state. Check your CI/CD dashboard, ask your team, or check the environment's deployment history if you are running on a platform that centralizes this, before assuming the lock is actually stale.
3. Run the command with the ID from step one: [.code]terraform force-unlock b8814894-4a5f-217b-e97b-c4f5c02a1f88[.code]. Confirm the prompt with [.code]yes[.code], or add [.code]-force[.code] if you are running this non-interactively.
4. Verify the fix by re-running the command that originally failed, such as [.code]terraform plan[.code]. If it proceeds past the locking step without error, the lock is cleared.

Unlocking remote state: alternatives to force-unlock

Wait instead of forcing: -lock-timeout

If two operations occasionally overlap for a few seconds, for example two CI jobs kicking off close together, [.code]force-unlock[.code] is the wrong tool. The [.code]-lock-timeout[.code] flag tells Terraform to wait for the lock to clear on its own instead of failing immediately:

terraform plan -lock-timeout=5m

This is worth setting as a default in CI pipelines that run plan, apply, or destroy operations back to back, so a brief overlap resolves itself instead of surfacing as a lock error at all.

Manual removal as a last resort

Occasionally [.code]force-unlock[.code] itself fails, usually because the backend is unreachable or credentials cannot reach the lock record. HashiCorp's guide to recovering state from backup covers this scenario directly. In that situation, the remaining options are backend-specific: delete the lock object from S3 or GCS, edit or remove the DynamoDB item, or break the Azure blob lease as shown above. All of these bypass Terraform entirely, so treat them with the same caution as [.code]force-unlock[.code] itself.

Coordinate before you unlock

Whichever method you use, confirm no other process is mid-write before you touch the lock, and consider pulling a backup first with [.code]terraform state pull[.code]. Never use [.code]-lock=false[.code] as a standing workaround for frequent lock errors. It disables the protection entirely rather than resolving whatever is causing the contention.

Troubleshooting force-unlock errors

The lock ID does not match

[.code]force-unlock[.code] will refuse an ID that does not match the current lock. This almost always means you are using a stale ID from an old error message. Re-run the failing command to get the current lock's ID and try again.

Permission errors during force-unlock

Clearing a lock requires write or delete access to wherever the lock record lives, for example [.code]s3:DeleteObject[.code] on the lock object, or the equivalent DynamoDB, GCS, or Azure permission. A permissions error here usually points to the credentials Terraform is running with, not the lock itself.

The same lock error comes back immediately

If you clear a lock and it reappears right away, something is still actively writing to that state. Stop and investigate before unlocking again. This pattern usually means step two of the worked example above was skipped.

Managing state locking at scale with env zero

Clearing a stuck lock by hand does not scale once a platform team is managing hundreds of environments across multiple backends. Ad Hoc Tasks in env zero let you run a command, including [.code]terraform force-unlock -force LOCK_ID[.code], directly on the environment's deployment container from the UI. That means resolving a stuck lock does not require local CLI access, a checked-out copy of the Terraform configuration, or direct credentials to the backend that holds the state.

By default, ad hoc tasks are restricted to organization administrators, since they allow arbitrary commands against a live deployment container. Teams that want to delegate lock-clearing to platform engineers without granting full admin access can do that with a custom role scoped to just that permission.

It is worth distinguishing this from Environment Locking in env zero, which is a separate, deliberate governance control rather than Terraform's automatic state lock. Locking an environment in env zero blocks deploys, destroys, plans, and drift detection outright, with a reason attached for anyone else who looks at it, and it stays in effect until someone with permission unlocks it. A Terraform state lock, by contrast, is transient by design and normally clears itself within seconds. If you are troubleshooting a “locked” environment in env zero and [.code]force-unlock[.code] does not seem relevant, this distinction is usually why.

Key takeaways

• [.code]terraform force-unlock LOCK_ID[.code] manually clears a stuck state lock. It does not touch your infrastructure, and on most backends it does not touch your state data either.
• Only use it when you are certain the process that created the lock is no longer running. Unlocking an active operation risks a corrupted state file.
• The lock ID is usually sitting right in the error message. You only need to hunt through backend-specific tooling when troubleshooting without that message in hand.
• S3 no longer needs DynamoDB for locking. [.code]use_lockfile = true[.code] has been the supported path since Terraform 1.11.
• [.code]-lock-timeout[.code] prevents most stuck-lock situations in CI before they happen, by waiting instead of failing immediately.

Frequently asked questions

Q. How do I fix a Terraform state lock?

Run [.code]terraform force-unlock LOCK_ID[.code], using the ID from the [.code]Error acquiring the state lock[.code] message. Only do this once you are certain no other operation is currently running against the same state.

Q. What is Terraform state locking for?

State locking prevents two operations from writing to the same state file at the same time, which is one of the most common causes of state corruption. Terraform acquires the lock automatically before any operation that could write state and releases it when the operation finishes.

Q. Can force-unlock corrupt my Terraform state?

[.code]force-unlock[.code] itself does not modify your infrastructure or your state data; it only removes the lock record. The risk is indirect: if you unlock a state that another process is actively writing to, that process and yours can both write at once, which can corrupt the state file.

Q. Does the S3 backend still need DynamoDB for state locking?

No. Since Terraform 1.11, the S3 backend supports native locking through [.code]use_lockfile = true[.code], using S3 conditional writes instead of a separate DynamoDB table. The older [.code]dynamodb_table[.code] argument still works but is deprecated.

Q. How do I avoid stuck state locks in the first place?

Avoid cancelling Terraform runs mid-operation, set [.code]-lock-timeout[.code] in CI so brief overlaps wait instead of failing, and use a platform that centralizes deployment history so you can quickly confirm whether a lock is stale before clearing it.

The Problem

You asked, we listened. This has become the most requested feature we’ve ever had.

That’s right, we’re finally launching the Terragrunt run-all functionality.

We’ve had Terragrunt support since December 2020, with that initial release supporting running a specific folder at a time. Terragrunt, however, has a neat capability to execute multiple Terraform modules at once, with the bonus of being able to define module dependencies too.

With this new release, it’s now possible to run parallel folders of Terraform modules. Admins can configure the template to `run-all` modules, with users able to toggle the functionality when they run the template.

What is Terragrunt? Why use Terragrunt run-all?

Terragrunt is an excellent solution for keeping your infrastructure configurations DRY (Don’t Repeat Yourself), managing multiple Terraform modules, and managing remote state. It allows us to define Terraform code only once, irrespective of how many environments we’re running.

By using Terragrunt, we’re able to eliminate duplicate backend code. Instead, we can manage Terraform state once in the root directory, and it’s inherited by all child modules.

Finally, Terragrunt allows us to execute Terraform commands on multiple modules. We only need to run one command for all modules, instead of executing for each independent module.

This is the convenience of Terragrunt “run-all”.

With “run-all”, not only do we run the Terraform command on multiple modules, it creates a dependency graph between those modules, and allows the passing of outputs as inputs to different modules.

How to use Terragrunt run-all in env0

How to use Terragrunt in env zero using a template

Here’s how to enable “run-all” in the UI when creating your Terragrunt template

When creating a new template in env0, first select the Terragrunt template type. Next, expand the “Advanced” options and click the check box to “Execute run-all commands on multiple modules”.

How to execute Terragrunt run-all in env zero without a template

To execute Terragrunt run-all without creating a new template in env0, select “Create new environment” from within your project.

Choose the VCS option to “Create an environment from a VCS integration.” This allows us to create a new environment directly from your source code repo.

Select the Terragrunt template type. Expand the “Advanced” options. Click the checkbox to “Execute run-all commands on multiple modules”

In Step 2, you’ll choose your VCS, select the repository, branch, and folder which contains your Terragrunt files.

In Step 3, define the ‘variables.

Finally, name your environment, and select your desired env zero features, like Drift Detection or Plan on Pull Requests.

Deployment Example

Here in the deployment logs we can see the results of the `run-all plan`. Expanding to dive deeper will show whether or not the configuration is valid, as well as any changes that were committed in a human readable format for ease of troubleshooting. Depending on whether we prefer to apply before or after merge, we can also insert an approval step to satisfy governance and compliance requirements.

After our changes have been approved, we can view the logs for `run-all apply`

Since Terragrunt run-all environments will include output from each Terraform module, we’ll list the outputs in the UI by presenting them as a separate group for each module folder.

Terragrunt and env zero - Manage your infrastructure at scale

Rejoice all ye Terragrunt users, for the day has come that Terragrunt run-all has come to env0! This allows you to execute Terraform commands on multiple modules, with the added ability to define dependencies. This is perfect for creating more complex Terraform environments with multiple modules, setting up the dependencies between them, and for keeping your Terraform code DRY!

By using Terragrunt with env0, you’ll also get approval flows, plan on pull request, continuous deployment, ephemeral environments, scheduling and drift detection. This provides the robust functionality needed to automate, manage and govern Terragrunt at scale.

‍

Terraform's simple syntax, ease of use, and strong provider support have made it popular among DevOps teams and infrastructure engineers. In this blog, we will discuss best practices you should follow for writing clean, scalable and efficient Terraform code, focusing on:

1. Consistent structure and naming convention
2. State management
3. Infrastructure automation
4. Security and compliance
5. IaC reusability and templating

We'll also provide some examples of how env zero can help align to these best practices to optimize your Terraform workflows.

Naming convention and folder structure

Debugging issues due to poor structuring and naming conventions can be a pain. You can avoid such problems by adopting a consistent naming convention for your Terraform configuration files, for instance by using underscores (_) in names.

Here are some best practices that will help you maintain readable, manageable, and scalable Infrastructure-as-Code.

• Use short descriptive names to clearly describe the purpose of the resource, making it readable in outputs or error messages. 
• Avoid sensitive information in resource names, such as company secrets or personally identifiable information (e.g., [.code]ec2_instance[.code]), and ensure consistent naming conventions to maintain manageable infrastructure.
• Stick to lowercase letters to avoid issues with case sensitivity in different operating systems or platforms (e.g., [.code]ec2[.code]).
• Use underscores (_) over dashes (-) as name separators. Some providers’ resources may not accept dashes - plus, it allows for easy refactoring  (e.g., [.code]ec2_instance_1[.code]).
• Include the environment in the name to avoid conflicts when managing resources across multiple environments (like production, staging, and development), and enhance clarity (e.g., [.code]prod_database_instance).[.code]).
• Standardize a structure and agree on naming conventions on an organizational level to maintain consistency. A common pattern might be <environment>_<application>_<resourceType>_<name> (e.g., [.code]prod_app_webserver_01[.code]).
• Employ reusable variables to make your code more maintainable. In Terraform, you can define your variables in a.tf file and use them from there.

Another thing to consider are the Terraform configuration files and folder structures. Effectively organizing Terraform those can help you maintain scalability, readability, and ease of management, especially as your infrastructure grows. 

Here are some best practices for structuring your Terraform projects:

• Keep your main configuration .tf files (root module) in the root of your project directory.
• Use separate directories for each environment (e.g., prod/, stage/, dev/) with a consistent naming convention. Each directory can have its version of main.tf, variables.tf, outputs.tf, etc., pointing to the appropriate modules.
• Include a README.md in your root directory and each module directory, explaining the project or module's purpose, usage, and any prerequisites. 
• Implement file organization to isolate components needed for your Terraform code, such as variables.tf, outputs.tf, providers.tf, terraform.tf – depending on your needs, for easy management.

‍How env zero can help

With env0, you can manage multiple environments without duplicating your files, saving you valuable time and effort. This environment structure can reflect the way your files and folders are organized in Git. 

For example, one thing you can do is create a project in env0, and set up environments for development, testing, and production. Each of these will link to the same directory, but you can give them their specific settings, like [.code]bucket_name[.code]. 

Visit env zero docs to learn more about Environments and this guide to learn about Environment Discovery. (also covered below)

On the standardization side of things, env zero also provides several features to help with rolling out and maintaining consistent naming conventions.

One of these is Shared Variables, which allows you to create a hub for your variables in project settings, listing your options in a user-friendly drop-down feature. 

This ensures the entire team stays on the same page and follows the extract the same standardized naming convention.

Visit env zero docs to learn more about Variables Management.

State Management

Properly managing your state files can help you avoid misconfiguration or production issues. 

Apply these best practices to help manage Terraform state:

• Store Terraform state files in a centralized location like AWS S3 or Azure Blob Storage to avoid local state conflicts and ensure restricted access across your team.
• Avoid storing state files in any version control system (VCS) repositories to prevent exposing secret credentials as plain text.
• Enable state locking in your backend to manage Terraform state, prevent concurrent state modifications, and ensure your changes are applied sequentially.
• Schedule regular backups of your state files to ensure quick recovery from data loss or corruption.
• Consider using separate state files for bigger projects to reduce complexity. Otherwise, you might run into problems like managing dependencies between resources and risking state corruption.

How env zero can help

env zero simplifies managing your infrastructure's state with features like environment locking, drift detection, and ad-hoc task management. 

With these features, there's no need to manually set up locks, S3 buckets, or other configurations, enabling you to manage your infrastructure easily.

Environment Locking feature in env zero lets you track all versions of your state files by setting up a remote state backend, allowing the use of the same state file across environments to keep them organized and to avoid state file clashes.

Visit env zero docs to learn more about  Environment Locking.

Drift Detection gives you better control over your infrastructure. This feature in env zero helps you monitor and catch unintended changes early, informing you about any discrepancies in your setup so you can fix them before they become problems. 

When a drift detection job is executed, you'll see its status under the Deployments tab.

Check out this guide for more information about Drift Detection.

Ad-hoc tasks in env zero provide a central hub for executing ad-hoc commands like [.code]terraform state mv[.code] and [.code]terraform import[.code], enabling team members to run tasks centrally as needed without risking infrastructure stability. 

In a typical scenario, you would have to run these ad-hoc commands on your local system, making it hard to track who did what.

Visit env zero docs to learn more about Ad-hoc tasks.

Infrastructure Automation

By automating infrastructure, Terraform creates opportunities to minimize errors and speed up rollouts. This will reduce manual tasks and ensure that changes to the infrastructure are traceable, repeatable, and reversible. 

Here are some best practices to follow while automating your infrastructure.

• Use a version control system (like Git) to automate the provisioning, and de-provisioning of your infrastructure and maintain the application lifecycle. This lets you track changes, collaborate effectively, and roll back when needed, keeping a consistent infrastructure state acting as the Single Source of Truth (SSoT). 
• Design automation scripts and configurations to be idempotent. Running them multiple times on the same system should produce the same result, improving reliability and error handling.
• Test, validate, and plan your infrastructure code using your automation pipelines or scripts before applying the changes by creating a pull request. Keep your environments (test, non-prod, etc.) similar to each other.
• Schedule your infrastructure deployments and destroy unused resources using automation to prevent manual intervention, which can disturb the infrastructure state. 

How env zero can help

env zero offers features like environment discovery capabilities that automatically create and destroy environments based on pull requests. This enables you to stay within the GitOps flow and maintain Git as your main source of truth for code management, auditability, etc.

This also enables teams to test new features in isolated environments without manual intervention, reducing operational overhead.

Check out this guide for more information about Environment Discovery.

With env0, you can also set custom TTL policies to automatically destroy environments after a specified period to maintain clean infrastructure. Visit env zero docs to learn more about TTL Policies.

Additionally, you can schedule environment provisioning and de-provisioning to align with business hours or project needs, further optimizing resource usage.

Visit env zero docs to learn more about Scheduling.

For OpenTofu users, env zero provides CI testing to automate module testing in the private registry. This allows you to ensure your modules are validated and function as expected before deployment. 

Check out this guide for more information about Modules CI Testing.

‍Security and Compliance  

Detecting vulnerabilities early is key to creating a secure and compliant system. Every one of your team members must follow the appropriate automated security and compliance checks to ensure the security of the infrastructure and meet the organization’s standards. Implement these best practices to ensure your system is secure and compliant.

• Implement Role-Based Access Control (RBAC) to ensure users have the appropriate permissions to execute tasks that align with their roles and responsibilities.
• Maintain detailed audit logs of user activities to track changes, access, and system events for accountability and compliance purposes.
• Use tools like Checkov or OPA to ensure that the infrastructure is thoroughly scanned for vulnerabilities before executing [.code]terraform apply[.code].

How env zero can help

Custom Role-Based Access Control (RBAC) roles come as default in env0, which mean you can assign permissions to individual users based on their roles and responsibilities. 

The project’s admin can view detailed audit logs in env zero to track team activity and monitor all activities around the infrastructure without any special configuration. Audit logs in env zero would provide the following information:

Visit env zero docs to learn more about RBAC roles and audit logs.

env zero also allows you to integrate the Checkov plugin into your env zero deployments to scan your Terraform code for vulnerabilities and ensure adherence to best practices. The plugin will install and execute the Checkov binary. 

Moreover, you can use native OPA (Open Policy Agent) integration to add approval flows within your env zero deployments to implement granular security and compliance policies. 

These are just a few examples. Click here to learn more about evn0 Plugins.

IaC Reusability and Templating

Implementing reusability and templating can increase efficiency by allowing teams to use parameterized templates and modular components. 

Here are some best practices for implementing these capabilities in your Infrastructure-as-Code:

• Apply modularization by breaking your configuration into reusable modules, functions, or classes. While doing so, use a descriptive, consistent naming convention across your organization.
• Use the parameterization technique in your IaC code to increase reusability across different environments and configurations.
• Implement shared variables to maintain consistency and provide reusability across teams.
• Create template repositories with predefined IaC templates for frequently used configurations.
• Ensure that modules and templates are environment-agnostic to work across different environments without modification, relying on parameterization.

‍How env zero can help

In addition to the previously mentioned reusable variables, env zero also provides you with the option to manage a shared private modular registry, where teams can easily exchange modular components. 

This maintains uniformity across various projects and environments, facilitating the secure sharing and reuse of these modules within your organization.

Visit env zero docs to learn more about Modular Registry.

Additionally, the env zero also enables template reuse, allowing you to create shared templates based on your specific IAC framework, version, and other configurations by attaching your template repository. 

Using these, you and your team can create new environments without duplicating work or creating new configurations. 

‍

Visit env zero docs to learn more about Templates.

‍Conclusion

We have explored many of Terraform's best practices, their value to your project, and their long-term benefits in your infrastructure development. 

However, these are not the universal guidelines and our suggestions here may or may not work, depending on the nature of your project, its size, and other requirements. 

This is exactly where env zero comes in – a flexible tool that lets you apply the things that could help and skip those that won’t, while always reducing your workload. 

By combining collaboration options with governance capabilities, it allows you to pave the ‘golden path’ that makes sense for you in a quick, user-friendly manner. 

Frequently Asked Questions

Q: What is the best practice for storing a project's Terraform state file?

The best practice for storing a project's Terraform state file is to use a remote backend, such as AWS S3, Google Cloud Storage, or Terraform Cloud. This ensures state consistency, supports collaboration, and provides secure access and versioning.

Q: How does env zero help with Terraform state management?

env zero simplifies state management by providing a secure, remote backend with versioning, environment locking, and drift detection capabilities.‍

Q: What role does env zero play in managing multiple Terraform environments?

env zero offers features like environment discovery and variable reuse, making automatically creating, managing, and destroying various Terraform environments easier.

Q: How can env zero enhance security and compliance in Terraform projects?

env zero integrates with security tools like Checkov, TFlint and OPA and offers RBAC and audit logging to enforce security policies and compliance in Terraform deployments.

Q: How does env zero support IaC reusability and modularity with Terraform?

env zero provides a module registry and predefined templates, enabling teams to manage reusable Terraform modules and simplify infrastructure setup.

‍

New to either tool? Our Terraform getting-started tutorial covers the core workflow for both Terraform and OpenTofu, so you have the right foundation before reading this comparison.

The discussion around OpenTofu vs. Terraform is often framed as a tooling comparison. In practice, it is an operational decision that affects how infrastructure is governed, audited, and evolved over time.

Most organizations evaluating this change are not starting from zero. They already manage production cloud infrastructure defined with Terraform, supported by mature Infrastructure-as-Code practices, established change management processes, and strict compliance requirements. The real concern is whether the alternative can be adopted without disrupting existing environments, workflows, or reliability guarantees.

This article focuses on that reality. It explains what changes and what does not in OpenTofu vs. Terraform, how migration paths work for existing environments, and what enterprise teams should evaluate around governance, state, and long-term operations.

Terraform vs OpenTofu – A Practical Comparison for Existing Infrastructure

When teams compare Terraform vs OpenTofu, the similarities are immediately apparent.

Both tools rely on declarative configuration, use HashiCorp Configuration Language (HCL), and share the same provider ecosystem. The execution lifecycle (plan, review, and apply) remains unchanged, as does the underlying state file format. Reusable modules, provider integrations, and configuration patterns continue to function without modification.

Because the project was designed with backward compatibility in mind, existing Terraform configurations do not require refactoring. For most teams, this means the comparison does not hinge on syntax or feature gaps. Instead, the OpenTofu vs. Terraform discussion quickly shifts toward operational impact once infrastructure is already provisioned and actively managed.

Why OpenTofu Exists

The project emerged after HashiCorp changed Terraform’s license to the Business Source License (BSL). While Terraform remains widely used, the license change introduced uncertainty for organizations that depend on open-source tooling for long-term commercial use.

The alternative is released under the Mozilla Public License 2.0 (MPL 2.0) and governed by the Linux Foundation. This governance model emphasizes transparent decision-making, open contribution, and predictable licensing terms. For enterprise teams, this reduces concerns around vendor lock-in and future licensing changes that could affect internal platforms.

In the OpenTofu vs. Terraform comparison, licensing is not a daily operational concern, but it strongly influences long-term platform strategy, especially in regulated environments.

Infrastructure as Code Remains the Foundation

Both tools follow the same Infrastructure-as-Code principles.

Infrastructure definitions are declarative, version-controlled, reviewed before execution, and applied through automated workflows. These characteristics support repeatability, auditability, and reliability across environments.

Because compatibility is preserved, existing Infrastructure-as-Code repositories do not need to be restructured. Configuration management practices remain intact, allowing DevOps and platform engineering teams to continue working with established workflows rather than relearning fundamentals.

This continuity is the foundation that makes adoption feasible in large organizations.

What Migration Actually Means in OpenTofu vs. Terraform

In enterprise contexts, migration is often misunderstood.

Migration does not mean rewriting configuration, rebuilding environments, or replacing providers. Instead, it refers to switching the execution engine while preserving everything around it.

Most organizations already operate environments with production-ready controls: access restrictions, approval gates, compliance checks, and audit logging. A valid migration must preserve these guarantees.

In practical terms, migration means existing environments continue to run as they are today, using the same state, the same approvals, and the same operational safeguards.

Migration Path from Terraform to OpenTofu

A realistic migration path includes several non-negotiable characteristics.

Existing environments remain unchanged. The same state file continues to be used. Approval workflows and compliance requirements remain intact. Rollback to Terraform remains possible until a tofu apply is executed. Because OpenTofu may update state metadata, teams should treat the migration of a specific state file as a forward-only move unless they maintain a pre-migration state backup.

Any approach that requires duplicating environments, copying state, or introducing parallel pipelines increases risk and operational complexity. The safest migration path treats the new engine as a drop-in execution replacement, not as a separate system.

This allows organizations to migrate incrementally, environment by environment, rather than through a single disruptive cutover.

State Management in Terraform vs OpenTofu

State management is one of the most sensitive aspects of Infrastructure-as-Code.

Both Terraform and its alternative share the same state file structure, enabling environments to transition execution engines without state conversion. Preserving state continuity is critical for maintaining historical context, enabling reliable drift detection, and supporting disaster recovery processes.

Recreating or duplicating state files introduces avoidable risk and complicates recovery scenarios. In the OpenTofu vs. Terraform discussion, preserving state management continuity is a prerequisite for production readiness.

Operational Impact of OpenTofu vs. Terraform in Large Environments

Enterprise infrastructure rarely consists of a single team or environment. Most organizations manage development, staging, and production environments across multiple cloud providers, often with different ownership boundaries.

At this scale, reliability depends less on tooling choice and more on operational consistency. Predictable execution, stable state handling, and clear change management processes are what keep Infrastructure-as-Code sustainable.

Platform engineering teams evaluate OpenTofu vs. Terraform through this lens. The question is not how infrastructure is defined, but whether existing operational guarantees continue to hold as execution changes underneath.

Running Terraform and OpenTofu Side by Side

In practice, the decision is rarely all-or-nothing.

Common patterns include legacy environments remaining on Terraform while new environments adopt the alternative, or gradual migration based on risk profile. Temporary coexistence during evaluation is also common.

Supporting these scenarios requires tooling that can manage mixed environments without fragmenting governance, configuration management, or audit trails. env zero enables this model by allowing Terraform and OpenTofu environments to coexist under a single operational framework.

Automating the Terraform to OpenTofu Migration Process

When teams look for tools to automate migration, they are not looking for scripts.

They want to avoid manual cutovers, one-time projects, and irreversible changes. Automation, in this context, means making migration repeatable and low-risk.

With env zero, automation focuses on reusing existing state, preserving environment configuration, maintaining approval workflows, and allowing execution engine selection per environment. This aligns migration with established change management best practices.

Managing Mixed Terraform and OpenTofu Deployments Long Term

Many organizations continue operating mixed environments long after migration begins.

Long-term success depends on unified governance, centralized visibility, consistent approvals, reliable drift detection, and strong audit logging. These requirements apply regardless of which engine executes infrastructure changes.

env zero manages both execution paths under the same governance model, preventing fragmentation and reducing cognitive overhead for platform teams.

IaC Governance Does Not Change with OpenTofu

Governance requirements exist because of organizational scale, not tooling choice.

Enterprise Infrastructure as Code governance typically includes role-based access control, policy as code enforcement, compliance requirements, and structured change management processes.

In OpenTofu vs. Terraform, the key question is whether governance remains engine-agnostic. env zero applies the same controls regardless of execution engine, ensuring consistency across environments.

Related reading: Atlantis for Terraform: A practical guide to PR-driven infrastructure automation. Atlantis works with both Terraform and OpenTofu at the execution layer — relevant if your team uses PR comment-driven plan and apply alongside either engine.

OpenTofu vs Terraform for Platform Engineering Teams

From a platform engineering perspective, this decision is about operability.

Key questions include whether environments can migrate incrementally, whether state continuity is preserved, whether reliability guarantees remain intact, and whether audit logging continues without gaps.

Separating execution engines from operational workflows allows platform teams to adopt the alternative without redesigning their internal platforms.

Reliability, Compliance, and Production Readiness

Production readiness depends on predictable execution, stable state handling, compliance with internal controls, and clear rollback paths.

When adoption does not weaken these properties, it becomes a low-risk evolution rather than a disruptive change. This is where enterprise teams draw the line in the OpenTofu vs. Terraform discussion.

Cloud Providers and Provider Compatibility

Both tools rely on the same provider ecosystem, ensuring compatibility across cloud providers and infrastructure platforms.

Provider compatibility allows organizations to continue managing cloud infrastructure without modifying existing configurations or reusable modules, which is critical for operating at scale.

Best Practices for OpenTofu Adoption

For enterprise teams, proven best practices include migrating environment by environment, preserving state files, maintaining consistent governance, avoiding parallel pipelines, and monitoring drift continuously.

These practices reduce operational risk and support reliable infrastructure automation over time.

Technical Considerations for Enterprise Migration

While OpenTofu is a drop-in replacement, enterprise teams must account for these three technical realities before the first apply:

• The Forward-Only State Rule: OpenTofu is backward compatible with Terraform 1.5.x - 1.6.x. However, once you run tofu apply, the state file may be updated with OpenTofu-specific metadata. Standard Terraform CLI will likely view this state as unsupported. Always perform a state backup before the initial migration.
• Registry Whitelisting: OpenTofu uses registry.opentofu.org to source providers. If your CI/CD runners sit behind a strict firewall or use a private proxy (like Artifactory), you must whitelist this endpoint to avoid Provider Not Found errors during initialization.
• Feature Divergence and Lock-in: OpenTofu v1.7+ introduces features like Native State Encryption and Early Variable Evaluation. While these provide significant security and flexibility advantages, utilizing them makes your configuration incompatible with Terraform. Decide early if you are staying agnostic or moving to Tofu-first features.

Final Thoughts on OpenTofu vs. Terraform

At the configuration level, OpenTofu vs. Terraform is largely settled.

At the operational level, the decision depends on migration safety, state continuity, governance consistency, and long-term reliability.

env zero enables organizations to adopt the alternative while keeping existing Terraform environments stable, governed, and auditable.

That is what makes the OpenTofu vs. Terraform decision practical for enterprise infrastructure teams.

Looking for a broader comparison of IaC tools? Our guide to the best infrastructure as code tools and Terraform alternatives covers Pulumi, Crossplane, Ansible, and more.

Adopt OpenTofu Without Disrupting Existing Terraform Environments

Evaluating OpenTofu vs. Terraform does not have to be a high-risk, all-or-nothing decision.

env zero allows teams to run Terraform and OpenTofu side by side, reuse existing state files, and preserve approvals, audit logging, and governance throughout the migration process. Environments can transition incrementally, without rebuilding infrastructure or introducing parallel workflows.

If you’re exploring OpenTofu and want a practical way to migrate existing Terraform environments safely, env zero provides the control plane to do it without disruption.

To see how env zero supports Terraform and OpenTofu in practice, schedule your personal demo today.

FAQ's

Is OpenTofu a drop-in replacement for Terraform in existing environments?

Yes, OpenTofu is designed to be a drop-in replacement for Terraform, especially for versions up to Terraform 1.5.x–1.6.x. Both tools use the same configuration language (HCL), provider ecosystem, and execution model, which means existing infrastructure code can typically run without modification.

For most organizations, this means there is no need to refactor configurations, rewrite modules, or rebuild environments. The infrastructure definitions, workflows, and deployment processes remain intact, allowing teams to switch the execution engine without disrupting operations.

However, while compatibility is high, teams must still approach migration carefully. Once OpenTofu-specific features are used or state metadata is updated after a tofu apply, reverting back to Terraform may not be straightforward. This makes initial planning and state backup critical.

What does “migration” actually involve when moving from Terraform to OpenTofu?

Migration in this context does not mean rebuilding infrastructure or rewriting code. Instead, it refers to switching the execution engine that runs your existing Infrastructure-as-Code workflows while keeping everything else unchanged.

This includes preserving the same state files, approval workflows, compliance checks, and access controls. A proper migration ensures that infrastructure continues to operate exactly as before, without introducing new risks or inconsistencies.

The safest approach treats OpenTofu as a direct replacement for Terraform’s execution layer. This allows teams to migrate incrementally, environment by environment, rather than performing a risky, large-scale cutover.

How does state management work between Terraform and OpenTofu?

Terraform and OpenTofu share the same state file structure, which is what enables seamless transition between the two tools. This compatibility allows teams to reuse existing state files without needing conversion or duplication.

Maintaining state continuity is critical because the state file tracks the real-world infrastructure and ensures accurate planning, drift detection, and change execution. Any disruption to state can lead to unintended resource changes or loss of infrastructure context.

One important consideration is that after running tofu apply, the state file may be updated with OpenTofu-specific metadata. This makes the migration effectively forward-only unless a backup of the original Terraform state is maintained.

Can Terraform and OpenTofu be used together in the same organization?

Yes, many organizations run Terraform and OpenTofu side by side, especially during migration or evaluation phases. This allows teams to gradually transition environments based on risk, complexity, or business priorities.

For example, legacy or production-critical environments may remain on Terraform initially, while newer or lower-risk environments adopt OpenTofu. This phased approach reduces risk and provides flexibility in decision-making.

However, managing mixed environments requires consistent governance, visibility, and operational control. Without a unified system, teams may face fragmentation in workflows, audit trails, and compliance enforcement.

What should enterprise teams evaluate before adopting OpenTofu?

Enterprise teams should focus less on syntax or features and more on operational impact. Key considerations include whether migration can be done incrementally, whether state continuity is preserved, and whether existing governance and compliance controls remain intact.

Additional technical factors such as registry access (for provider downloads), state backup strategies, and potential feature divergence should also be evaluated. These elements directly impact production stability and long-term maintainability.

Ultimately, the decision should be based on whether OpenTofu can be adopted without weakening reliability, auditability, or control. For most enterprise teams, maintaining these guarantees is more important than the tooling choice itself.

If your evaluation is partly driven by HCP Terraform's pricing changes or the March 2026 free tier end, see The Best Terraform Cloud Alternative in 2026 for the full breakdown of env zero versus HCP Terraform.

Related: env0’s OpenTofu integration gives you policy enforcement, drift detection, and team governance on top of OpenTofu — out of the box.

Further reading: Can OpenTofu Become the HTTP of Infrastructure as Code? — exploring whether OpenTofu can become the universal open standard for IaC.

I’m excited to announce that the public beta of env zero is now live! It is totally free during the beta so click here and try it out. We’re also excited to announce that we raised a $3.3M Seed round from two of the best early stage VCs in the business, Boldstart Ventures in NYC and Grove Ventures in Tel Aviv!

env zero helps local and remote teams manage Infrastructure as Code (IaC) deployments in AWS, Azure, and GCP. env zero is the first cloud management platform built around enabling a company’s entire team with self-service while maintaining governance and cost control. We’ve had a number of our early partners using it for the last several months, to help their teams work more independently and relieve workload off their SRE/DevOps team.

Here is a minute long video explaining what env zero is:

‍

Why env0?

So why env0? To really understand the impact, you have to look back 20 years to the first datacenter revolution, with virtualization (as pioneered by VMware) completely changing how companies deployed hardware in their datacenters. Ten years ago we saw the second revolution, with the introduction of public clouds and the ability for companies to rapidly scale their infrastructure without adding hardware. Today we’re living in the growth phase of the third datacenter revolution; with Infrastructure as Code allowing a level of automation and management of the cloud that makes it possible for even the largest deployments to be effectively managed there.

IaC is already huge (basically every cloud has its own flavor, plus the massively popular Terraform open source project) and widely deployed already. But current IaC solutions, and really the entire underlying construct of Infrastructure as Code, are very focused on SRE and dedicated DevOps teams and improving their existing workflows, missing an opportunity to really help drive forward this next revolution in infrastructure management.

So starting in late 2018, I joined up with my old friend Omry Hay to figure out how to better connect the technical solution that is Infrastructure as Code to the actual needs of the business and the larger team. 

What We Do

The result of all this is env0. Instead of just providing an automation tool for your SRE team to manage infrastructure based on tickets they receive from devs, env zero enables your entire team to manage their own environments based on the templates, policies, and cost controls that you set up.

env zero is the first cloud management platform to offer a comprehensive solution that,

• Is built around providing your entire team with a self service solution to manage their own environments
• Automatically and recursively tags your deployed infrastructure and reports costs back to based on the projects and uses you’re spending, rather than just cloud resources (all without any manual configuration!)
• Works with all your existing cloud providers and Infrastructure as Code frameworks.

We’re excited because this feature set opens up a whole new range of capabilities and an ease of use that doesn’t exist today. Anybody can now easily enable their team to do things like,

• Automatically, provision an environment for reviewing every pull request, all from directly within the CI/CD pipeline
• Allow sales and support teams to quickly deploy custom demo environments for clients with one click
• Allow data scientists to provision their own clusters that are automatically torn down after meeting a TTL policy to prevent cost overruns
• ...plus many others!

Basically, if you want to empower your team, without losing visibility, predictability, and most importantly, control and governance of your public cloud security and cost, env zero is the right product for you.

So we encourage you all to try it out. If you’d like to learn more first, schedule a demo with us here. 

Ohad, Omry, and the entire env zero team

PS: If you use it, please share your feedback with us on @envzero or by emailing contact@envzero.com. Try it out, and help your organization to unlock the full potential of infrastructure-as-code!