Drift detection for
Terraform and OpenTofu

Start right now

Try for free

Terraform code helps you deploy your infrastructure, but it does not ensure that your code and the infrastructure continue to stay aligned.

Checking repeatedly for this consistent state requires constant patrolling.

Tfstate performs frequent check-ins on your infrastructure and takes action when discrepancies are found.

Scanning
Terraform and OpenTofu support
Scans downloadable and archived
Clean, drifted and failed scan reporting
Multiple custom scanning schedules
Live scanning and test scans
Fixed monthly spend limits
Multiple user login accounts
Local and remote Terraform state
Full API access to tfstate.com
Notification Actions
Email notifications
Slack notifications
Webhook/API notifications
GitHub and Gitlab issues
Customizable templates/payloads
AI readable summaries
Authentication Support
AWS IAM role authentication
AWS IAM user key authentication
GCP workload identity federation (WIF)
GCP service account authentication
GitHub public and private repository support
GitLab public and private repository support

What does this service actually do?

• It checks out your Terraform code from GitHub or Gitlab
• It runs a terraform plan which interrogates your AWS or GCP infrastructure
• It then takes action via Slack, Email or Webhook about any inconsistencies or drift
• It runs these scans hundreds or thousands of times per month as per your needs
• It targets and responds to different Terraform stacks in the way that suits you
• The notification actions are customizable, templateable, can use ChatGPT summaries, and are one-click snoozeable
• There is a dashboard of scans so you can see at a glance which Terraform stacks are healthy and which have drifted
• The output from each individual scan is always available so you can see what has actually changed and when

Who is this service for?

Tfstate is a service that is adopted by DevOps and Infrastructure teams across mostly tech and pharmaceutical industries.

The initiative to adopt it usually comes from top-down: either a team leader, CTO, or other technical leader chooses to adopt Tfstate because they want to provide a separate monitoring/alerting perspective on their deployed infrastructure.

Often this perspective is driven by a need to achieve compliance so the company can pass their SOC2 or ISO 27001 accreditation. This service is especially useful for SOC 2 Type II which has on-going compliance requirements.

If you lead a DevOps team and deploy hundreds of resources to the cloud, you may want to adopt Tfstate to ensure that your platform is stable and predictable. This helps to avoid nasty "click-ops" surprises, and ensures that all infrastructure that is deployed has been coded and peer-reviewed first.

Why does configuration drift matter?

It impacts you in two ways:

1. The infrastructure: What could be more important than your system not changing unexpectedly under your feet? The security, performance, stability and costing of your platform depend on it.

2. The code: Your team's terraform code should at all times represent what is in production. If it doesn't match up, then perhaps some process or rule has been broken, perhaps peer-review was skipped, perhaps someone logged in to the AWS or Google web console and changed things by clicking.

Won't GuardDuty and Cloudwatch cover my monitoring needs?

GuardDuty and Cloudwatch cover a magnitude more than tfstate.com and we're not trying to replace them, but they don't have access to your intended architecture, i.e. the way things should be according to you: according to your Terraform code.

Why build this, why not use HashiCorp?

• Because we can make it simpler. The other solutions do a lot more than us, but that means their implementations are very complex.
• Because the competitors put their pricing for drift detection behind a call to "Contact Sales", or they publish a figure that is upward of 20 times as expensive as us.
• Because we provide a service that does one very important thing, very well. We're not trying to replace 40 components of your tech stack, but rather provide a turn-key solution for one very important problem.

What versions of Terraform and OpenTofu do you support?

We support all versions of Terraform up until the recent HashiCorp license changes, and from then we provide compatibility via OpenTofu.

Terraform versions: 0.12, 0.13, 0.14, 0.15, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
OpenTofu versions: 1.6, 1.7, 1.8, 1.9

The version of Terraform that you're using is detected at scan time, and then we run our scans using the same version of Terraform (or OpenTofu) as you.

Note: OpenTofu provides full compatibility with Terraform and in our testing there has been no difference in scan results.

Can you auto-update my infrastructure to match my Terraform code?

There are no plans to support this. We only require read-only access to your infrastructure metadata. From a security and stability perspective we don't recommend granting a third-party the ability to modify your infrastructure.

How do you access my AWS infrastructure?

We'll provide you with a small snippet of Terraform code that either creates an IAM Role or an IAM User (depending on your preference). This Role or User has access to the AWS built-in ReadOnlyAccess policy but we've removed some of the high-risk permissions like S3:GetObject on all buckets.

You can review and (if necessary) adjust the Terraform file before applying it.

How do you access my GCP infrastructure?

We'll provide you with a small snippet of Terraform code that either sets up Workload Identity Federation or Service Account credentials (depending on your preference). WIF allows our systems to contact your GCP account without explicitly storing and managing credentials.

You can review and (if necessary) adjust the roles in the Terraform file before applying it.

What about other providers?

As long as the provider supports authentication via environment variables then it should be possible.

The tfstate.com interface allows you to enter custom environment variables that will be made available to the environment at scan time. Eg:

CLOUDFLARE_API_TOKEN="secret token goes here"

How do you access my Terraform code?

We have a small (minimal permissions) GitHub app that you can install into your GitHub account. You can manually select which repositories should be accessible to the app.

If using GitLab instead, we have to use an access token authentication flow.

What sort of notification actions are there?

There are four main action mechanisms built-in:

1. Email
2. Slack
3. POST request to anywhere you like
4. GitHub/Gitlab Issues

Each of these mechanisms comes with a sensible default template, that you can customize and override if you wish. There are around 20 template variables that you can use. Including template variables that give you a one-click link for snoozing notifications. And variables that contain ChatGPT summaries of your changes. The GitHub/Gitlab Issues mechanism automatically opens and closes an issue when drift is detected and resolved.

How does billing work?

Your first 100 scans are free. Try things out. No credit card required.

Once you've used the free scans, your scans are tallied each month and a stripe.com invoice will get sent your way (and you can set a hard limit on the monthly bill to prevent surprises).

Do you use AI?

Users may optionally choose to get OpenAI/ChatGPT summaries and severity classifications in their alerts. These provide a plaintext summary of the changes that have been detected, and their importance.

To do that we need to send a portion of the output from the terraform plan step to the ChatGPT API. The source code is never sent, just a portion of the plan output.

There are no additional fees for this.

It transforms raw output like this:

# aws_lambda_alias.main will be updated in-place
~ resource "aws_lambda_alias" "main" {
    ~ function_version = "418" -> (known after apply)
      id               = "arn:aws:lambda:us-west-2:999999999:function:my-function:prod"
      name             = "prod"
  }

# aws_lambda_function.main will be updated in-place
~ resource "aws_lambda_function" "main" {
      id                             = "my-function"
    ~ image_uri                      = "999999999.dkr.ecr.us-west-2.amazonaws.com/my-function:1726625404" -> "999999999.dkr.ecr.us-west-2.amazonaws.com/my-function:1726562540"
    ~ last_modified                  = "2024-09-18T02:10:49.000+0000" -> (known after apply)
    ~ qualified_arn                  = "arn:aws:lambda:us-west-2:999999999:function:my-function:418" -> (known after apply)
    ~ qualified_invoke_arn           = "arn:aws:apigateway::lambda:path/functions/arn:aws:lambda::9999999:function:my-fun:418/invocations" -> (known after apply)
      tags                           = {
          "Name" = "my-function"
          "type" = "prod worker"
      }
    ~ version                        = "418" -> (known after apply)

      # (4 unchanged blocks hidden)
  }

Plan: 0 to add, 2 to change, 0 to destroy.

And translates it to these template variables:

Summary of changes (AI_SUMMARY)
Eg:
Terraform would update the AWS Lambda function "my-function" and its alias "prod".

Long description of changes (AI_DESCRIPTION)
Eg:
Terraform would change the image URI of the Lambda function 'my-function' to a different version 'my-function:1726562540' in Amazon ECR. Additionally, Terraform would update the function version of the Lambda alias named 'prod' to a new version that would be determined after the apply.

Change severity (AI_SEVERITY)
Eg:
high

Change severity explanation (AI_SEVERITY_WHY)
Eg:
Changes to the code in Lambda functions and their aliases are classified as high importance because they will potentially affect security, application performance and behavior.

Connect your pipelines and code to our API, so you can directly configure new code repositories, or new infrastructure connections automatically.

Full API support means launching new ad-hoc scans can become a completely hands-off experience. See the API docs for demos and code samples.