HashiCorp Terraform is an infrastructure-as-code tool for declaring, planning, provisioning, changing, and tracking cloud and on-premises resources through reusable configuration files and provider integrations.
HashiCorp Terraform manages infrastructure by translating declarative configuration files into changes performed through provider APIs. Administrators and development teams describe desired resources with HashiCorp Configuration Language, initialize required providers and modules, review an execution plan, and then apply approved changes. Terraform records relationships between configuration and real infrastructure in state so later operations can determine which resources need creation, modification, replacement, or removal. Its provider ecosystem supports cloud platforms, SaaS products, infrastructure services, and self-hosted systems through separately released plugins. HashiCorp Terraform is therefore suited to repeatable provisioning, environment creation, cloud automation, infrastructure review, and workflows where configuration should be stored and versioned alongside other code.
HashiCorp Terraform separates configuration, provider plugins, modules, state, and execution plans so infrastructure changes can be reviewed before they reach remote systems. The init command installs required providers and modules, plan previews proposed actions, and apply performs the approved changes while updating state. Teams using Microsoft services can manage supported infrastructure through appropriate Terraform providers while keeping browser-based administration separate from command-line provisioning work. Remote backends and HCP Terraform can centralize state and coordinate team workflows, while reusable modules reduce duplication between environments. Version 1.16.0 adds import blocks inside modules, provider planned-private data support, a terraform_data store block for ephemeral and sensitive values, and additional provider capabilities.
The main benefit of HashiCorp Terraform is making infrastructure changes repeatable, reviewable, and easier to reproduce across environments. Declarative configuration records the intended result in files that teams can place under version control, compare during code review, and reuse instead of rebuilding resources manually through separate administration consoles. Execution plans show proposed changes before apply, giving operators an opportunity to detect unexpected creation, replacement, or deletion actions. State keeps resource identities linked to configuration, while providers translate the desired infrastructure into API operations for many different services. Modules help teams package common architecture patterns and apply consistent conventions across projects, accounts, or regions. Dependency analysis also allows unrelated resource operations to proceed without unnecessary serialization. HashiCorp Terraform can fit into automated delivery pipelines because initialization, validation, planning, and application are available through command-line workflows. Together, these capabilities reduce configuration drift, repetitive setup, and undocumented manual procedures while preserving explicit control over infrastructure changes.
HashiCorp Terraform uses declarative configuration to describe the infrastructure a project should have rather than requiring scripts that manually perform every creation step. Resources, relationships, variables, and outputs are expressed in configuration files. This lets teams review infrastructure changes as code, reuse definitions between environments, and keep intended architecture documented alongside application repositories.
The terraform plan command compares configuration, state, and refreshed infrastructure information to produce a preview of proposed actions. It identifies resources that would be created, changed, replaced, or destroyed before apply executes them. Reviewing this plan gives administrators a controlled checkpoint for catching unexpected infrastructure changes before they are submitted to provider APIs.
Terraform state records bindings between configuration resource instances and objects that exist in remote systems. The CLI uses these mappings and stored metadata to determine how future configuration changes should affect existing infrastructure. State is therefore central to accurate planning, updates, imports, replacements, and deletions, and shared environments require careful state storage and coordination.
Providers are separate plugins that let Terraform interact with cloud services, SaaS applications, network platforms, databases, and other APIs. Each provider contributes resource types and data sources specific to the system it manages. Independent provider versioning allows infrastructure integrations to evolve separately from the core CLI while dependency constraints help projects control compatible releases.
Modules package groups of related resources into reusable infrastructure components with inputs and outputs. Teams can create modules for recurring patterns such as networks, compute stacks, storage, or application environments, then call them from multiple configurations. This reduces duplicated code and provides a practical way to standardize architecture while still allowing controlled variation through module variables.
Terraform analyzes references and dependencies between resources to determine a safe order for operations. Resources that depend on others are handled accordingly, while unrelated operations can run in parallel when the provider permits it. This graph-based execution reduces the need for administrators to manually script every provisioning sequence and helps expose relationships within complex configurations.
Existing infrastructure can be associated with Terraform resource addresses so organizations can begin managing previously created resources without recreating them. Import blocks support configuration-driven workflows, and version 1.16.0 extends import blocks into modules. Import establishes the state association, while administrators still need suitable configuration that represents the imported resource and its intended management.
The Terraform CLI exposes initialization, formatting, validation, planning, application, state, workspace, import, output, and inspection commands that can be incorporated into repeatable development or delivery workflows. Machine-driven execution lets teams integrate infrastructure checks and changes with scripts and CI/CD systems while retaining configuration, provider constraints, plans, and state as explicit workflow components.
HashiCorp Terraform is used to define and manage infrastructure as code. It can provision, modify, import, and remove resources exposed through compatible providers, including cloud infrastructure, SaaS services, network systems, and other API-driven platforms.
The plan command previews the changes needed to move managed infrastructure toward the declared configuration. Apply performs the approved operations, such as creating, updating, replacing, or deleting resources, and then updates state to reflect the resulting infrastructure.
State maps declared resource instances to real objects and stores metadata Terraform needs for future operations. It helps the CLI determine which infrastructure already exists and what must change when configuration is updated.
Providers are plugins that connect Terraform with external APIs. They define the resource types and data sources available for a particular cloud platform, SaaS service, infrastructure product, or other supported system.
The latest stable release is version 1.16.0, released on August 26, 2026. It adds support for import blocks inside modules, planned private provider data, a terraform_data store block for ephemeral and sensitive values, computed nested provider blocks, and a Linux s390x binary.
Comments