Terraform 1.2 represents a pivotal checkpoint in HashiCorp’s infrastructure as code platform, combining foundational CLI changes that affect every user with a focused enterprise release for IBM Z and LinuxONE mainframe environments. The 1.2.0 release, dated May 18, 2022, introduced built-in credential handling, stricter transport security requirements, and new configuration validation primitives that changed how modules are authored and how state is managed. At the same time, IBM and HashiCorp advanced the Terraform for Z and LinuxONE capability to 1.2, delivering FICON and Open Systems Adapter automation and deeper integration with IBM Cloud Infrastructure Center. Together these tracks illustrate how Terraform 1.2 serves both broad platform hardening and mission-critical mainframe automation.
Terraform 1.2.0 Core Release and Upgrade Impact
Terraform 1.2.0 shipped with upgrade notes that directly impacted existing workflows around credentials, operating system support, and TLS. The release removed support for legacy transport security and changed credential precedence.
Upgrade notes introduced in 1.2.0 include:
- If you use the third-party credentials helper plugin terraform-credentials-env, you should disable it as part of upgrading to Terraform v1.2 because similar functionality is now built in to Terraform itself.
- The new behavior supports the same environment variable naming scheme but has a difference in priority order from the credentials helper.
- TFTOKEN environment variables will now take priority over credentials blocks in CLI configuration and credentials stored automatically by terraform login, which is not true for credentials provided by any credentials helper plugin.
- If you see Terraform using different credentials after upgrading, check to make sure you do not specify credentials for the same host in multiple locations.
- If you use the credentials helper in conjunction with the hashicorp/tfe Terraform provider to manage Terraform Cloud or Terraform Enterprise objects with Terraform, you should also upgrade to version 0.31 of that provider, which added the corresponding built-in support for these environment variables.
- The official Linux packages for the v1.2 series now require Linux kernel version 2.6.32 or later.
- When making outgoing HTTPS or other TLS connections as a client, Terraform now requires the server to support TLS v1.2. TLS v1.0 and v1.1 are no longer supported.
- Any safely up-to-date server should support TLS 1.2, and mainstream web browsers have required it since 2020.
- When making outgoing HTTPS or other TLS connections as a client, Terraform will no longer accept CA certificates signed using the SHA-1 hash function. Publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.
- The changes to Terraform's requirements when interacting with TLS servers apply only to requests made by Terraform CLI itself, such as provider/module installation and state storage requests. Terraform provider plugins include their own TLS clients which may have different requirements, and may add new requirements in their own releases, independently of Terraform CLI changes.
New features in 1.2.0 focused on module authoring safety and lifecycle control:
- precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further execution.
- replacetriggeredby is a new lifecycle argument for managed resources which triggers replacement of an object based on changes to an upstream dependency.
- You can now specify credentials for Terraform-native services using an environment variable named as TFTOKEN followed by an encoded version of the hostname.
The credential changes were significant because they centralized token handling inside Terraform. The TFTOKEN prefix scheme allows environment variables to override configuration blocks and login-stored credentials, creating a predictable precedence chain for Terraform Cloud and Terraform Enterprise access. The upgrade guidance to disable terraform-credentials-env and to upgrade the hashicorp/tfe provider to 0.31 reflects this shift.
The TLS hardening in 1.2.0 removed support for TLS 1.0 and TLS 1.1 for CLI-initiated connections and rejected CA certificates signed with SHA-1. These requirements apply to provider and module installation and state storage requests made by the CLI, not to provider plugin TLS clients, which retain their own requirements.
Enterprise Mainframe Automation with Terraform for Z and LinuxONE 1.2
Terraform for Z empowers teams by leveraging infrastructure-as-code through its consistent, scalable approach.
IBM and HashiCorp have once again raised the bar for enterprise automation. With the release of Terraform for Z and LinuxONE 1.2, we’re introducing capabilities that transform how organizations manage their most mission-critical systems. This release introduces Fiber Connectivity (FICON) and Open Systems Adapter (OSA) management, which helps support clients to automate networking and storage configurations with speed, consistency, and confidence.
Eight months ago, we set out with a clear mission: to deliver breakthrough capabilities that empower our z/OS clients to automate and innovate at scale. Today, we’re proud to deliver on that promise.
From day one, IBM Infrastructure and Software teams partnered closely with HashiCorp to design, develop, and rigorously test this capability. This collaboration reflects our commitment to helping clients simplify complexity and accelerate transformation across their most critical environments.
With this delivery, clients can automate key processes in their compute, networking and storage management, from definition to automation. In combination with our delivery in third quarter, clients can now automate an essential set of workflows where they define and stage updates to their systems, both production and development.
Users can initiate changes to these and other resources through a standard Integrated Development Environment (IDE) such as Microsoft VS Code. Terraform for Z integrates with IBM Cloud Infrastructure Center 1.2.5 to execute the state change commands that are captured in Terraform configuration files.
Key Innovations in IBM Cloud Infrastructure Center 1.2.5 include simplified virtualization, automation enablement, and strengthened compliance. These enhancements are more than technical upgrades—they represent a strategic advantage for our clients. By simplifying virtualization, enabling automation, and strengthening compliance, ICIC 1.2.5 helps organizations.
This release also includes an IODF transformer that simplifies the migration /translation of existing I/O definitions and configuration files to Terraform for Z. By transforming complex infrastructure management tasks into clear, automated workflows, we enable clients to accelerate modernization with confidence. This functionality gives system programmers a streamlined way to inspect deployed code, make necessary adjustments, and coordinate changes seamlessly through approved CI/CD pipelines. It’s about turning complexity into clarity and empowering teams to deliver with speed and precision.
The IBM Z and LinuxONE provider is used specifically for the management of resources that are unique to IBM Z and LinuxONE, such as LPAR, FICON, and OSA.
The following table summarizes the Terraform for Z 1.2 capabilities tied to IBM Cloud Infrastructure Center 1.2.5.
| Capability | Description |
| IBM Z and LinuxONE 1.2 release | Introduces FICON and OSA management for networking and storage automation |
| IBM Cloud Infrastructure Center 1.2.5 integration | Executes state change commands captured in Terraform configuration files |
| IDE support | Changes can be initiated through standard IDEs such as Microsoft VS Code |
| IODF transformer | Simplifies migration and translation of existing I/O definitions and configuration files to Terraform for Z |
| Workflow coverage | Automates compute, networking and storage management from definition to automation for production and development systems |
Container Delivery and Docker Images for Terraform
Terraform can be delivered as a container image. Automatic builds of Terraform are provided. See README for more use and info.
Terraform is an infrastructure as code (IaC) tool that allows you to build, change, and version infrastructure safely and efficiently. This includes low-level components such as compute instances, storage, and networking, as well as high-level components such as DNS entries, SaaS features, etc. Terraform can manage both existing service providers and custom in-house solutions.
Running Terraform inside a Docker container requires more configuration than running the Terraform CLI executables directly. Unless you need container isolation, we recommend using the non-containerized Terraform CLI packages.
The Terraform team publishes a Docker image to this repository for each official release of Terraform CLI. Each versioned image includes the Terraform CLI release with the same version number.
These images wrap the terraform executable, allowing you to run Terraform subcommands by passing in their names and arguments as part of docker run. For example, the command below uses the 'latest' tag to generate a plan using the most recent version of Terraform:
docker run -i -t hashicorp/terraform:latest plan
Note that for production use, we recommend specifying a specific version instead of using latest.
You will likely need to further configure your container so that Terraform can access your configuration files and provider credentials.
The Docker delivery model provides a consistent runtime for CI pipelines and ephemeral environments while emphasizing that container usage adds configuration overhead compared to native CLI packages.
CI/CD Integration and Version Management with setup-terraform
Version pinning and automated installation are central to reproducible Terraform pipelines. The setup-terraform action supports constrained version selection and optional wrapper outputs.
Examples are:
- "<1.2.0"
- "~1.1.0"
- "1.1.7"
All three installing the latest available 1.1 version.
Prerelease versions can be specified and a range will stay within the given tag such as beta or rc. If no version is given, it will default to latest.
.terraform_wrapper
- (optional) Whether to install a wrapper to wrap subsequent calls of the terraform binary and expose its STDOUT, STDERR, and exit code as outputs named stdout, stderr, and exitcode respectively. Defaults to true.
This action does not configure any outputs directly.
The version constraint examples show how ranges can lock major or minor lines while still allowing patch updates. The wrapper option enables capturing Terraform execution results as action outputs for downstream steps.
Long-Term Evolution Beyond 1.2
The Terraform platform continued to evolve after the 1.2 era. Release notes for later development builds illustrate the direction of the codebase.
For v1.16.0-alpha20260701, July 01, 2026, new features included:
- Store PlannedPrivate data for providers
- New store block in terraform_data that can handle ephemeral and sensitive values
- Providers can now use nested blocks as computed values
- import: add support for import blocks inside modules
- We now produce builds for Linux s390x (zLinux)
- workspace: The workspace list command can now produce machine-readable output when supplied with the -json flag
- Resource action triggers can now use on_failure modes of halt, taint, or continue
Enhancements in the same build included:
- feat(cli): terraform state show accepts a -json flag
- Show info when resources are left behind due to skip_cleanup
- Action configuration now has a new caller symbol which contains the object value from the calling resource
- Actions can now use beforedestroy and afterdestroy events
- cloud: Render a summary of Terraform policy evaluation outcomes for plan and apply runs against HCP Terraform
- policy: Resolve the policy plugin entitlement (host, token, organization) from the configured cloud/remote backend for init, plan, and apply, instead of the plugin reading credentials itself
- child module outputs with unreferenced deprecated nested attributes no longer return deprecation warnings
These later changes, including s390x builds for zLinux, demonstrate continued investment in mainframe and enterprise platform support that aligns with the earlier Terraform for Z 1.2 initiatives.
Conclusion
Terraform 1.2 marks a convergence of platform hardening and enterprise mainframe enablement. The 1.2.0 CLI release introduced built-in credential handling via TFTOKEN environment variables, removed legacy TLS 1.0, TLS 1.1 and SHA-1 certificate support, raised the minimum Linux kernel requirement, and added precondition, postcondition, and replacetriggeredby constructs for safer module authoring. The upgrade path required disabling the third-party terraform-credentials-env helper and upgrading the hashicorp/tfe provider to 0.31 to preserve credential behavior.
In parallel, Terraform for Z and LinuxONE 1.2 delivered FICON and OSA automation, IODF transformation capabilities, and integration with IBM Cloud Infrastructure Center 1.2.5, enabling IDE-driven change initiation in VS Code and automated staging of production and development system updates. The IBM Z and LinuxONE provider continues to target resources unique to mainframe environments such as LPAR, FICON, and OSA.
Delivery options expanded through official Docker images that wrap each CLI release, with guidance to prefer native packages unless container isolation is required. CI/CD adoption is supported by setup-terraform with precise version constraints and optional wrapper outputs for capturing execution results.
Taken together, Terraform 1.2 established a more secure, expressive, and enterprise-ready foundation that later releases extended with planned private data stores, nested block computed values, s390x builds, and enhanced policy and workspace tooling. The release remains a reference point for organizations balancing broad IaC platform adoption with the demands of mission-critical mainframe automation.