HCP Terraform
Developer ToolsDrive HCP Terraform from AI agents. Agents create and configure workspaces, queue plan and apply runs, gate downstream steps on run status, manage Terraform and environment variables including secrets, and read the current state version.
What This Integration Enables
Infrastructure is the highest-stakes write surface a company has, and HCP Terraform already encodes the right instinct: plan first, apply second. What the platform cannot do on its own is carry that pause to a person with the context to decide, in the place they will actually see it. FlowRunner closes that gap. Agents create and configure workspaces, queue plan and apply runs including destroy and plan-only speculative runs, poll run status to gate downstream steps, manage Terraform and environment variables including write-once secrets, and read the current state version to surface resource counts and the state download URL. The result is HCP Terraform's confirmation step turned into a routed decision instead of a pending state. The run that would sit awaiting confirmation becomes a message in front of the right engineer, with the plan's intent summarized and two buttons that map to Apply Run and Discard Run. This is the [digital andon cord](/concepts/digital-andon-cord) applied to infrastructure: the line stops on its own, and a person restarts it deliberately.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Push to plan to approved apply
A push lands in [GitHub](/integrations/github). The agent resolves the workspace, queues the run with Create Run, and polls Get Run until Terraform finishes planning. It then posts the run to [Slack](/integrations/slack) with the workspace name, the run message, and whether the plan includes deletions. An engineer replies approve, and the agent calls Apply Run with a comment recording who approved, then keeps polling until the run reaches applied and reports the outcome in the same thread.
Ephemeral environments, provisioned and retired
When a review environment is requested, the agent calls Create Workspace with the right Terraform version and working directory, seeds configuration with Create Variable, marking secrets sensitive so their values are write-once, and queues the first run. At teardown, the order of operations is the whole game: the agent queues a destroy run and waits for it to apply, because Delete Workspace removes the workspace without destroying the infrastructure it manages. Only after the destroy completes, and a person confirms, does the workspace itself get deleted.
Failed runs become owned incidents
A scheduled drift-check flow queues plan-only runs across production workspaces. When Get Run reports a run errored, the agent opens an incident in [PagerDuty](/integrations/pagerduty) carrying the run ID and workspace, and attaches the workspace's resource counts from Get Current State Version so the on-call engineer starts with the blast radius in view. Runs that plan clean simply log their status, and the flow stays silent when silence is the correct report.
Human-in-Loop Highlight
Apply Run executes real changes against real infrastructure, and a destroy run tears resources down; neither has an undo, only a recovery. So the FlowRunner agent holds every apply it did not pre-clear. The gate reads like this in the infra channel: "Run run-Kx7RJm on workspace prod-network is planned. The plan modifies 6 resources and destroys 2, including an NAT gateway. Apply, or discard?" The engineer who owns that workspace makes the call. Approve, and the agent calls Apply Run with the approver recorded in the comment; decline, and Discard Run closes the run so it can never be applied later by accident. The same rule guards Delete Workspace, a force delete that erases state versions and run history and cannot be undone. The agent does the queueing, polling, and reporting all day without help. The moment a change would touch what production is built on, it stops and asks, which is exactly what [human-in-the-loop](/concepts/human-in-the-loop) infrastructure automation means.
Agent Capabilities
17 actionsWorkspaces
6- List Workspaces Enumerate the organization's workspaces with name search, tag filters, and each workspace's Terraform version, execution mode, and current run status.
- Get Workspace by Name Resolve a workspace by its name within the organization. The lookup that precedes every run and variable operation.
- Get Workspace by ID Load a workspace by ID, returning settings, VCS configuration, and the current run relationship.
- Create Workspace Provision workspaces with Terraform version, working directory, execution mode, and auto-apply behavior.
- Update Workspace Adjust a workspace's settings as environments evolve.
- Delete Workspace Force-delete a workspace with its state versions and run history. Cannot be undone and does not destroy the managed infrastructure, which is why flows destroy first, then ask, then delete.
Runs
6- Create Run Queue a plan against a workspace, with support for destroy runs, plan-only speculative runs, and refresh control. The entry point of every change.
- Get Run Poll a run through pending, planning, planned, applying, and applied or errored.
- List Runs Audit a workspace's run history in reverse chronological order.
- Apply Run Confirm and apply a run awaiting confirmation, with a comment recorded alongside the apply. The action a named human approval sits directly in front of.
- Cancel Run Interrupt a run mid-plan or mid-apply.
- Discard Run Discard a planned run so its changes can never be applied. The decline button of the approval gate.
Variables
4- List Variables Read a workspace's Terraform and environment variables, with sensitive values masked, to audit configuration before a run.
- Create Variable Provision variables with category, HCL parsing, and sensitivity control. Sensitive values are write-once, so secrets can be set by the flow without ever being readable from it.
- Update Variable Change a variable's value or settings as configuration evolves.
- Delete Variable Permanently remove a variable from a workspace as part of configuration cleanup.
State
1- Get Current State Version Read the latest state version's serial, Terraform version, resource and provider counts, and the hosted download URL for the raw state. The fastest honest answer to what does this workspace actually manage.
Frequently Asked Questions
What can FlowRunner do with HCP Terraform?
FlowRunner agents can run List Workspaces, Get Workspace by Name, and Get Workspace by ID in HCP Terraform, plus 14 more actions.
Does connecting HCP Terraform to FlowRunner require OAuth?
No. HCP Terraform connects to FlowRunner with an API key, no OAuth flow required.
Can HCP Terraform trigger a FlowRunner workflow automatically?
HCP Terraform doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with HCP Terraform
$100 in credits. No card required. Connect in minutes.