Everything you need to know about using Terraform or OpenTofu with Slack

Most DevOps teams already live in Slack, so it makes sense to push operational events there too. Whether that's an alarm firing in New Relic or a Terraform or OpenTofu apply that just failed, Slack is where people will see it. This post walks through the different ways Slack and Terraform fit together, and calls out the couple of places where OpenTofu behaves differently.

The general idea is ChatOps: using a chat tool like Slack or MS Teams to run operational work through external integrations. Instead of hunting for status in five different consoles, the relevant information lands in a channel where the team can read it and respond together.

One of the most common cases is wiring Slack up to Terraform so you get a message when specific run events happen. Automated notifications based on Terraform runs keep everyone in the loop and tend to speed up deployments. Everything below applies equally whether your workspaces run Terraform or OpenTofu, since the two tools share the same configuration language and provisioner behavior; the Scalr integration explicitly supports both, and we call out the one place — community provider and module registries — where the two diverge.

Why Send Terraform or OpenTofu Events to Slack?

Here are a few reasons why you may want to integrate Terraform or OpenTofu with Slack:

1. Reduce context switching: If your development teams already work in Slack to review Terraform code and pull requests, then why change where they are working? Slack notifications give you real-time updates on key events during the Terraform provisioning process, so everyone hears about changes, successes, or issues right away.
2. Reduce noise: Slack notifications are only good if they are useful and you are alerted to take action when actually needed. Most teams will likely want a Slack notification when a Terraform apply fails, but not for every Terraform event.
3. Approve or deny applies from the channel: This is similar to context switching, but being able to approve a Terraform apply directly from Slack makes the team more efficient. When you can get a notification that an approval is needed, read the plan output, and act on it all in one place, you cut down on context switching and the whole team can see what's going on. Not all methods below give you the ability to approve directly from Slack, but the Scalr option does.

How Do You Set Up a Slack Webhook?

If you are setting up an integration with Slack that does not use a supported Slack app, you'll likely need to create your own app in Slack. To do that, go to api.slack.com, click "Your Apps," and create a new app from scratch. For the features and functionality, you'll likely only need to enable "Incoming Webhooks," which will provide you with a webhook URL and a sample curl request:

curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' YOUR_WEBHOOK_URL_HERE

This webhook URL is what your custom integrations will call to create the Slack message when triggered. See more on creating Slack webhooks here.

What Are the Two Ways to Integrate Terraform with Slack?

Use the local-exec Provisioner

The most basic way to integrate Terraform with Slack, without a third-party tool, is to use Terraform's local-exec functionality. The local-exec provisioner calls the Slack webhook URL from within your configuration to send a message. This works identically in OpenTofu, since tofu apply uses the same provisioner block syntax as terraform apply:

resource "null_resource" "example" {
  provisioner "local-exec" {
    command = <<-EOT
      curl -X POST -H 'Content-type: application/json' \
        --data '{"text":"The run has completed"}' \
        YOUR_WEBHOOK_URL_HERE
    EOT
  }
}

This works, but it's not a good fit at scale, since the code has to be added to every workspace or configuration file that runs. It's better suited to a one-off use case.

The Scalr Integration with Slack

The Scalr app in the Slack app directory sends a Slack notification when Terraform or OpenTofu run events happen and allows users to approve runs directly from Slack. This scales well because you set it up outside the Terraform configuration files. A Scalr admin creates the integration with Slack and defines which Scalr environments and workspaces should trigger a Slack message to a specific Slack channel. Since the setup lives outside the Terraform configuration files, end users don't have to remember to do it when they set up a workspace. Scalr's own documentation describes the integration as pushing notifications for your "Terraform and OpenTofu lifecycle" — there's no separate setup path for OpenTofu workspaces.

Scalr also provides more granularity by allowing users to choose which run events trigger a Slack notification:

Run mode:

• All runs: notifications are sent for a plan or an apply run.
• Plan & apply runs: notifications are sent for an apply run.
• Plan only runs: notifications are sent for a plan run.

Events:

• Approval required: an approval from a user is required before the apply can run.
• Run finished successfully: the plan or apply finished successfully.
• Run errored: the plan or apply resulted in an error.
• Drift detected: Scalr executed a drift run and found that the workspace had drift.

Lastly, the Scalr app for Slack also allows for approvals directly from Slack. Slack users are sent all the information they need to make a decision about whether to approve the run:

• Terraform plan output
• Open Policy Agent results
• Cost estimation

Once the Slack user is ready to approve, they can give an approval reason which is then sent back to Scalr and can be seen prior to the apply event happening. Actions triggered from Slack still require the underlying Scalr IAM permission for that action (for example, runs:create to start a plan or apply); Slack does not bypass Scalr's permission model. The authorization flow simply links your Slack identity to your Scalr identity so Scalr can check that you hold the right permissions before executing the action.

See more in the Scalr documentation here. Plans and pricing are on the pricing page.

Does Any of This Work Differently in OpenTofu?

Mostly no. OpenTofu is a Terraform fork, so the HCL configuration language, provisioner blocks, and the Scalr integration all behave the same way. The one place things diverge is where community providers and modules come from.

OpenTofu maintains its own registry at registry.opentofu.org, run by the Linux Foundation, and it does not automatically mirror everything published to the Terraform registry. Module and provider authors have to publish to each registry separately. In practice, that means:

• If tofu init can't find a community Slack provider or module that you know exists on the Terraform registry, it's probably because the author hasn't published it to OpenTofu's registry yet.
• You can still use it by adding the registry hostname explicitly in the source address, which tells OpenTofu to pull directly from HashiCorp's registry instead of its own default:

terraform {
  required_providers {
    slack = {
      source  = "registry.terraform.io/pablovarela/slack"
      version = "~> 1.0"
    }
  }
}

Outside of that registry nuance, everything in this post — the webhook approach, the local-exec provisioner, and the Scalr Slack app — works the same for Terraform and OpenTofu workspaces.

Other Slack-Terraform Resources

Is There a Slack Terraform Provider?

The main focus of this post is integrating Slack notifications with Terraform, but you can also manage Slack itself with Terraform. Slack doesn't maintain its own provider, but there's a trusted community provider for Slack resources. At the time of writing, this Terraform provider for Slack has over 1.2M downloads with 13 contributors, based on information pulled from library.tf.

This provider gives you the ability to manage resources like slack_usergroup and slack_conversation. As noted above, confirm it's published to registry.opentofu.org before running tofu init against it unprefixed — otherwise, add the explicit registry.terraform.io host to the source address.

What Slack Terraform Modules Exist?

While there aren't any modules to actually manage Slack resources, the most popular module involving Slack is terraform-aws-notify-slack, which integrates an AWS SNS topic with Slack channels.

At the time of writing, the module has been downloaded over 2M times and has 43 contributors according to library.tf. The same registry caveat applies here as with providers: confirm the module is published to OpenTofu's registry, or reference it with an explicit host, before pulling it into an OpenTofu configuration.

Where Should You Start?

There are several ways to use Terraform or OpenTofu and Slack together. You can manage Slack itself with the community Slack provider, connect an SNS topic to a Slack channel through Terraform, or use a platform like Scalr to push run events into a channel without touching your configuration files. For most DevOps teams working with infrastructure as code, Slack has become the place where this kind of operational work happens.

Key Sources Used

1. Scalr Slack integration documentation
2. Slack incoming webhooks documentation
3. Terraform local-exec provisioner documentation
4. OpenTofu provider requirements documentation
5. pablovarela/slack provider on library.tf