Since 2014, Terraform provider growth has been explosive. At Terraform's initial launch, there were less than ten providers. Today, there are nearly 70 builtin providers that ship with Terraform and countless more are distributed as plugins by the community. Community is and will continue to be the core of Terraform's adoption and success.
Currently all builtin providers are distributed as part of the main Terraform binary. As an unintended side-effect, small bug fixes, new features, or security releases for a single provider are blocked until the next release of the main Terraform binary for distribution. About a year ago, Terraform adopted a two-week cadence for releases to rapidly deliver updates and fixes to users, but even this cycle proved to be too long. As upstream providers add new APIs, features, and improvements, Terraform users want to leverage those new technologies as soon as they reach stability. To that end, we are excited to announce upcoming changes to the provider ecosystem in Terraform 0.10 – individually distributed provider plugins.
The goal of separating providers into separate GitHub repositories and deliverable binaries is to increase the velocity of Terraform improvements by giving more ownership and contribution access to more community members.
Each provider's source now lives independently in its own repository in the Terraform Providers GitHub organization. The split of individual providers from Terraform core enables each provider to define its own release cadence, versioning, and documentation.
Provider plugins are no longer included with the main Terraform binary distribution. Instead, they are distributed separately and are fetched and installed on-demand by the terraform init command. This new approach allows users to upgrade individual providers, use custom or patched providers, and remove providers in isolation. It also decreases the size of the initial package distribution, since Terraform will only download the providers it needs.
Since provider plugins are versioned separately from Terraform itself, individual version constraints allow users to restrict against upstream breaking changes. Just like git init, terraform init will become a key part of the daily Terraform workflow. The prior mechanisms for installing third-party providers will continue to be supported. Maintainers of third-party providers may optionally make use of the new versioning mechanism by following the upgrade process which will be made available shortly.
This new structure also gives more ownership to community members. Previously anyone with commit access to a provider also had commit access to all of Terraform, which led us to keep the contributor pool small. Under this new model, each provider has its own permissions, and repository owners are empowered to control access to their code without granting them access to all of Terraform. This will empower more owners and contributors across more providers.
The core of Terraform will still live at the hashicorp/terraform GitHub repository and will be maintained by HashiCorp employees and trusted external contributors.
A project re-organization of this magnitude is not without disruption. We have done our best to make this migration as seamless as possible, but there are always unplanned edge cases.
Due to the nature of the provider split, Pull Requests will not migrate. Over time, we will do our best to work with pull request authors to migrate their change requests to the provider repositories. We ask that any future community contributions or issues are made against the new provider repositories.
In order to minimize disruption, there will not be another release in the 0.9 series. Instead, the next release of Terraform will be 0.10.0-beta to help smooth out this new process. We realize this provider migration may cause disruption for some users in the short-term, but we're confident the change is in the best long-term interests to maintain the velocity of Terraform's improvements. The Terraform team will be extra active and responsive on the Terraform mailing list these next few weeks to ensure the transition is as smooth as possible. Please let us know if you have any concerns.
Thank you to everyone who has helped to make Terraform the leading tool for managing infrastructure as code. Whether you fixed a typo, resolved a bug, wrote a provider, or built the graph engine, you and the contributions of 1,105 others have played a key role in the success of the project. Thank you for giving us the opportunity to work with you, and we look forward to what we can continue to build together.
Learn how to use best practices-based modules to build production-grade Terraform deployments on AWS.
Learn a quick method for getting started with the Cloud Development Kit (CDK) for Terraform using TypeScript as infrastructure code and provisioning on Microsoft Azure.
The Terraform AWS Provider now offers users the ability to define default tags at the provider level, simplifying tag management.