Leveraging null_resource in Terraform for Complex Operations

Terraform Resources 101 (Quick Recap)#

Terraform’s core mechanic is the resource block. It tells the provider, “Hey, make this thing exist.”

1
resource "azurerm_windows_function_app" "app" {
2
  name     = "example-function-app"
3
  location = "East US"
4
}

That’s your bread-and-butter declaration. Define the desired state, then let Terraform do the heavy lifting.

But sometimes you don’t want to create anything in the cloud. You just want Terraform to do something. Run a script, call a webhook, poke Jenkins with a stick. That’s where null_resource comes in.

What the Hell is null_resource?#

null_resource is exactly what it sounds like. A Terraform resource that manages nothing. No infrastructure, no API objects. Just logic.

But here’s the trick. It still behaves like a real resource. It supports lifecycle actions (create, destroy, etc.), it can depend on other resources, and most importantly, it supports provisioners and triggers.

1
resource "null_resource" "example" {
2
  triggers = {
3
    always_run = timestamp()
4
  }
5

6
  provisioner "local-exec" {
7
    command = "echo 'Triggering follow-up actions'"
8
  }
9
}

This block runs every time, because timestamp() changes on every plan. Handy when you need to kick off external processes after infra changes.

Triggers: The Secret Sauce#

Triggers are the magic behind null_resource. They control when it gets re-executed. Not based on resource state, but on changes to arbitrary data you hand it.

Example:

1
triggers = {
2
  hash = filemd5("config.json")
3
}

Now your null_resource only re-runs when config.json changes. That’s gold in CI/CD setups where you’re tracking file changes, API responses, or even environment variables.

Real-World Scenarios (Where null_resource Actually Earns Its Keep)#

1
resource "null_resource" "notify" {
2
  triggers = {
3
    infra_version = var.release_tag
4
  }
5

6
  provisioner "local-exec" {
7
    command = "curl -X POST https://hooks.slack.com/services/XXX -d 'Terraform apply complete: ${var.release_tag}'"
8
  }
9
}

1
data "azurerm_storage_account" "example" {
2
  name                = "examplestorageaccount"
3
  resource_group_name = "my-rg"
4
}
5

6
resource "null_resource" "trigger_on_key_change" {
7
  triggers = {
8
    key = data.azurerm_storage_account.example.primary_access_key
9
  }
10

11
  provisioner "local-exec" {
12
    command = "echo 'Access key has changed, executing...'"
13
  }
14
}

1
resource "null_resource" "smoke_test" {
2
  depends_on = [azurerm_function_app.example]
3

4
  provisioner "local-exec" {
5
    command = "curl -sf http://example-app.azurewebsites.net/health || exit 1"
6
  }
7
}

The Cleaner Alternative: terraform_data (1.4+)#

Starting in Terraform 1.4, HashiCorp shipped a new built-in: terraform_data. It does what null_resource does, with less baggage, and without leaning on a provider plugin.

1
resource "terraform_data" "run_command" {
2
  provisioner "local-exec" {
3
    command = "echo 'Still works!'"
4
  }
5
}

You lose triggers, for now anyway. But it’s first-party and cleaner for one-off tasks. Reach for it when you’re scripting or injecting data during apply without pretending to be a cloud resource.

null_resource vs terraform_data: When to Use What#

TL;DR: need triggers? Stick with null_resource. Everything else, migrate to terraform_data. It’s the cleaner, future-proof option.

Final Thoughts#

If Terraform were a programming language, null_resource would be its eval(). Powerful, dangerous, misused 99% of the time.

But in the hands of someone who knows what they’re doing? It bridges the gap between infrastructure and orchestration. Think CI/CD pipelines, edge cases, the situations where Terraform alone just can’t model reality.

Don’t go overboard, though. If you find yourself writing a bash script inside a null_resource that runs a Python script that generates more HCL, maybe reconsider your life choices.

Pro Tip: Pair null_resource with depends_on and triggers for controlled chaos. Or use terraform_data if you want to sleep at night.