Terraform Actions: Tackling Day 2 Operations

Last Updated on November 29, 2025 by Arnav Sharma

So Terraform Stacks went GA and gave us a native way to handle multi-environment deployments without leaning on Terragrunt. Great. But here’s the question that keeps popping up in every infrastructure team’s chat: what happens after you provision everything?

You know what I’m talking about. Scaling clusters when traffic spikes. Rotating those TLS certificates before they expire at 2 AM on a Sunday. Patching instances. Running that Ansible playbook you’ve been meaning to automate. Right now, most of us are juggling a mess of cron jobs, Lambda functions, and shell scripts with comments like “DO NOT MODIFY” (which means someone definitely will).

HashiCorp just dropped Terraform Actions into public beta at HashiConf 2025, and it’s tackling this exact problem. This isn’t just another way to trigger a Terraform run. Actions let you define post-provisioning tasks directly in your HCL code, as actual first-class blocks that can run automatically after an apply, when drift gets detected, or whenever you need them. Oh, and they built in native Red Hat Ansible integration from day one.

Let me walk you through why this matters and how it actually works.

The Day 2 Problem We’ve All Been Living With

Terraform has always been brilliant at Day 0 and Day 1 operations. Standing up infrastructure? Perfect. Making updates to existing resources? Works great. But then comes everything else:

• Those custom scripts you hook into terraform apply with post-execution flags
• External tools like Rundeck or Ansible Tower that live completely outside your Terraform workflow
• Drift detection that requires someone to manually investigate and fix
• The dreaded “just SSH in and handle it” approach (no judgment, we’ve all done it)

The real cost isn’t just the technical debt. It’s the inconsistency. Your infrastructure state lives in Terraform, but your operational tasks live everywhere else. Nothing’s versioned together. Code reviews don’t catch operational changes. Audit trails are scattered across five different systems.

Terraform Actions aims to fix this by letting you define imperative operational tasks right alongside your declarative infrastructure code. Same repository. Same review process. Same execution context.

How Actions Actually Work

Actions introduce a new block type at the top level of your configuration. Here’s a simple example:

action "scale_eks_nodegroup" {
  trigger = "post_apply"

  provider = "kubernetes"

  script = <<-EOT
    aws eks update-nodegroup-config \
      --cluster-name ${terraform.workspace}-eks \
      --nodegroup-name workers \
      --scaling-config desiredSize=${var.desired_count}
  EOT

  depends_on = [aws_eks_node_group.workers]
}

What’s happening here? After Terraform successfully applies your EKS node group, this action automatically scales it based on whatever value you’ve set in var.desired_count. No external scheduler needed. No separate script to maintain.

The trigger system is where things get interesting. You’ve got four options:

• post_apply runs immediately after a successful apply. Perfect for configuration tasks that need to happen right after infrastructure comes up.
• drift executes when HCP Terraform detects configuration drift. Think of this as your auto-remediation layer. Someone manually tweaked a security group rule? Your action can revert it automatically.
• manual gives you on-demand control from the UI, CLI, or API. This is your break-glass-in-case-of-emergency scaling handle.
• schedule accepts cron expressions for recurring tasks. Weekly patching at 3 AM on Saturdays? Monthly compliance reports? You got it.

The Ansible Integration Is Actually A Big Deal

Here’s where things get really interesting. HashiCorp partnered with Red Hat to build first-class Ansible support directly into Actions:

action "patch_servers" {
  trigger = "schedule"
  schedule = "0 3 * * SAT"

  provider = "ansible"

  playbook = "./playbooks/patch-and-reboot.yml"

  inventory = component.servers.public_ips

  extra_vars = {
    ansible_become_pass = vault.secret.data.sudo_pass
  }
}

This matters because it eliminates the traditional split between infrastructure and configuration management. Terraform provisions your servers. Ansible configures them. But until now, these lived in completely separate worlds with their own workflows, execution contexts, and state management.

Now you can:

• Generate Ansible inventory dynamically from Terraform outputs and components
• Pull secrets from Vault without exposing them in code
• Run playbooks as part of your normal Terraform workflow
• Get full execution logs in the same place as your infrastructure changes

For the majority of enterprises already running both tools, this is massive. No more context switching between systems. No more wondering if your Ansible runs actually match your Terraform state.

Real Scenarios You Can Actually Use Today

Let me show you a few patterns I’ve been testing that solve real problems.

Automatic Scaling on Drift

action "autoscale_on_high_cpu" {
  trigger = "drift"

  condition = "aws_cloudwatch_metric_alarm.high_cpu.status == 'ALARM'"

  provider = "aws"

  script = "aws autoscaling set-desired-capacity --auto-scaling-group-name ${aws_autoscaling_group.app.name} --desired-capacity ${var.max_capacity}"
}

Your monitoring detects high CPU. Drift triggers because actual state diverges from desired state. The action automatically scales your ASG without anyone needing to page the on-call engineer.

Certificate Rotation Before Expiry

action "rotate_tls_cert" {
  trigger = "manual"

  provider = "vault"

  script = "vault write -force pki/issue/my-role common_name=app.example.com"
  
  then_apply = true
}

The then_apply flag is clever. After Vault generates your new certificate, Terraform automatically runs another apply to update any resources that reference it. No manual coordination needed.

Scheduled Database Maintenance

action "pg_vacuum" {
  trigger = "schedule"
  schedule = "0 4 * * SUN"

  provider = "postgresql"

  query = "VACUUM ANALYZE;"
}

Every Sunday at 4 AM, your PostgreSQL database gets vacuumed and analyzed. It’s versioned in your infrastructure code. It runs in the same execution context as your other operations. If you need to change the schedule or the query, it goes through the same review process as everything else.

What You Need to Know About the Beta

Let’s be realistic about where this is right now. Actions launched in public beta, which means there are some limitations:

It’s currently available only in HCP Terraform (Plus tier and above) and Terraform Enterprise. The open-source CLI doesn’t have it yet, though HashiCorp is targeting Terraform 1.10+ for that release.

Provider support at launch includes AWS, Kubernetes, Ansible, HTTP, and Vault. More providers are coming, but if you need something specific, you might be waiting a bit.

There’s no automatic rollback on action failure yet. If your action partially executes and then fails, your apply will fail, but you might need to clean up manually.

How This Fits Into the Bigger Terraform Picture

Take a step back and look at what HashiCorp has shipped in the last year. Stacks went GA and solved multi-environment orchestration. Actions just dropped in beta to handle Day 2 operations. Terraform Search is making bulk imports actually feasible. MCP servers are letting AI agents interact with Terraform directly. Project Infragraph is coming soon with real-time dependency visualization.

Terraform is evolving from a provisioning tool into a full infrastructure lifecycle platform. If you’re still thinking about it as just a way to create and destroy resources, you’re missing where the ecosystem is heading.

The pattern is clear: HashiCorp is trying to keep everything in one place. Your infrastructure definitions, your operational tasks, your orchestration logic, your documentation, your change history. All in code. All versioned. All reviewable.

Getting Started Today

If you want to try this out:

1. Make sure your organization is on the latest HCP Terraform (Actions rolled out November 2025)
2. Enable the feature flag under Organization Settings → Features → Terraform Actions (beta)
3. Check the official docs at https://developer.hashicorp.com/terraform/cloud-docs/actions
4. Join the public beta feedback portal. HashiCorp is iterating quickly based on user input.

I’ve been testing Actions with a few different teams, and the feedback has been consistent: this solves real problems they’ve been working around for years. The question isn’t whether Day 2 operations belong in your infrastructure code. It’s whether you want to keep maintaining them in six different places with six different workflows.

What’s your biggest Day 2 headache right now? Drop it in the comments and I’ll sketch out how an Action could handle it.Retry