DevOps

What's New with Terraform + Ansible: Collection 2.0, pyTFE, and Dynamic Inventory

Workflow diagram showing Terraform provisioning infrastructure that flows into Ansible inventory for configuration management.

The Glue Code Problem

If you run Terraform and Ansible together, you know the tax: custom scripts, CLI wrappers, and brittle glue code whose only job is keeping the two tools in sync. It breaks during upgrades, it's a pain to maintain, and it creates governance gaps because the two sides have disconnected permission models.

HashiCorp's June 2026 update targets exactly that seam. The headline pieces are the Terraform Ansible Collection 2.0 (powered by a new Python SDK called pyTFE), an experimental dynamic inventory plugin, and an enhanced Terraform actions experience. The framing across all of it is the Day 0 / Day 1 / Day 2 lifecycle—provisioning, configuration, ongoing operations—and getting Terraform and Ansible to hand off cleanly across those stages.

Here's what each piece actually does and which ones matter for fleet automation.

Terraform Ansible Collection 2.0, Powered by pyTFE

The collection gives you an API-first way to manage Terraform workflows directly from Ansible. From inside a playbook you can manage workspaces and runs, use remote execution, pull Terraform outputs, and fold Terraform operations into existing Ansible automation—while keeping governance through role-based access controls.

The point is eliminating the custom glue code. Instead of maintaining your own scripts to bridge ansible-playbook and the Terraform API, the collection becomes the supported integration layer. Less maintenance, fewer things that break on upgrade.

pyTFE: The SDK Underneath

pyTFE is the official Python SDK for HCP Terraform and Terraform Enterprise. HashiCorp is announcing it at 1.0 / GA alongside the collection. It covers projects, workspaces, runs, tasks, teams, users, and state management.

If you've ever written a one-off Python script hitting the Terraform API directly—and if you manage Terraform at any scale, you have—pyTFE is meant to replace that with a stable, supported client. The Ansible collection is itself built on pyTFE, so the same foundation powers both your playbook integrations and any custom Python automation you build.

⚠️ Version-check before you wire this into production: as of this writing the public collection repo still lists pytfe>=0.1.5 as its requirement, so confirm the GA package versions and the minimum the 2.0 collection actually pins before you pin your own. Day-old releases take time to propagate across Galaxy, the Red Hat catalog, and PyPI. Don't assume the GA bits are live everywhere just because the blog says GA.

Dynamic Inventory: The Part That Actually Saves You Time

This is the most useful piece if you manage infrastructure that changes.

The old problem: when Terraform provisions a new resource, Ansible has no idea. You either write a custom inventory script, run manual reconciliation, or accept drift between what Terraform knows and what Ansible sees. Every team running both tools has built some version of this bridge, and every version is fragile.

The new tfc_inv.py plugin (experimental, shipped in Collection 2.0) closes the gap. It pulls the latest Terraform state version directly from HCP Terraform via pyTFE, parses the Terraform-managed resources, and generates Ansible inventory automatically—without needing Terraform CLI access or backend credentials on the box running Ansible.

That last detail matters for security. Your Ansible control node gets the inventory it needs through a scoped HCP Terraform token, rather than holding backend credentials (S3 keys, state-bucket access) that a custom inventory script would otherwise require. Smaller credential footprint on the control node, smaller blast radius if it's compromised.

⚠️ It's experimental and HashiCorp is explicitly soliciting feedback, so treat it as a candidate for staging, not an unattended production dependency yet. Pin the collection version, test the inventory output against a known state, and have your existing inventory method ready to fall back to. An inventory plugin that silently returns a partial host list is the kind of failure that runs a playbook against the wrong set of machines.

Enhanced Terraform Actions Experience

Terraform actions—introduced last year—let you run Day 2 operations directly from Terraform: scaling, triggering operational workflows, remediation, all without modifying your infrastructure config.

The update adds a dedicated actions page in HCP Terraform: a central place to see available actions, invoke them from the UI, and review past invocations. For a workspace you can see what actions exist, when they last ran, how they were triggered, and the outcome.

For the Terraform + Ansible crowd, this is mostly an observability win. If you're triggering Ansible automation from Terraform actions, you now have a single view of what ran, when, and what happened—instead of stitching that history together from logs across both tools.

Actions in Terraform Stacks

Actions can now be lifecycle-triggered from Terraform Stacks configurations. Stacks are a config layer written as code that sits on top of your modules, letting you manage collections of related infrastructure together across environments and teams.

With actions in Stacks, you can auto-invoke approved operational workflows in response to stack lifecycle events—validation, remediation, scaling, or configuration management that naturally follows an infrastructure change. The value is consistency: the operational task fires off the lifecycle event instead of relying on someone remembering to run it.

What's Worth Adopting, and When

Not all of this carries equal weight for a working infrastructure team.

Adopt soon: pyTFE, if you maintain custom Python against the Terraform API. Swapping brittle homegrown clients for a supported SDK is a clear win with little downside, once you've confirmed the GA version.

Pilot in staging: the dynamic inventory plugin. It solves a real, recurring drift problem and reduces credentials on your control node—but it's experimental, so prove it against your state before trusting it unattended.

Useful if you're already invested: the collection 2.0 governance/RBAC improvements and the actions page. High value if you run AAP and trigger cross-tool workflows; lower priority if your Terraform↔Ansible handoff is simple.

⚠️ The honest caveat on all of it: this is HCP Terraform / Terraform Enterprise tooling. If you run open-source Terraform (or OpenTofu) with a self-managed backend and no HCP, most of this—pyTFE's HCP API coverage, the tfc_inv.py plugin pulling from HCP state, the actions page—doesn't apply to you directly. The drift problem is still real; you'd just keep solving it with the community cloud.terraform inventory plugin against your own state backend rather than this HCP-bound path. Worth knowing before you plan a migration around it.

Conclusion

The direction here is sound: infrastructure lifecycle management is more than provisioning, and the Terraform→Ansible handoff has been held together with glue code for years. A supported SDK, an automatic inventory bridge, and better visibility into cross-tool operations all chip away at that.

For most teams the dynamic inventory plugin is the standout—it kills a fragile script everyone maintains and tightens the control node's credential footprint at the same time. Pilot it, confirm the GA versions before pinning, and keep your existing inventory path as a fallback until the experimental label comes off.