A seemingly routine Slack conversation between platform engineers has ignited a wider debate about the quality of Terraform and OpenTofu providers — and put Cloudflare’s provider in the spotlight.
The discussion began when engineer Oliver Mulelid-Tynes vented his frustration after yet another problematic upgrade of the Cloudflare Terraform provider. Despite describing himself as someone who rarely gets angry, he admitted that working with the provider was “almost bringing [him] to the point of going postal”, due to frequent breaking changes and manual fixes required in the Terraform state.
The exchange, shared publicly on LinkedIn by Matt Gowie, CEO and CTO of infrastructure consultancy Masterpoint, quickly resonated with many DevOps and platform engineers who had experienced similar pain.
Minor upgrade, major headaches
In the screenshot posted by Gowie, Mulelid-Tynes explains that his latest problems appeared when upgrading the provider from version 5.4.0 to 5.13.0. On paper, that should be a minor update. In practice, he describes it as yet another release that introduced breaking changes, forcing him to manually edit the Terraform state to correct broken routes and an orphaned worker.
The engineer criticises not only the instability but also the way some issues have been handled on GitHub, describing responses as arrogant and dismissive of users who expect that a minor version bump will not silently break infrastructure.
For teams that manage large-scale environments with Terraform or OpenTofu, this kind of behaviour is more than an annoyance. State “surgery” is risky, time-consuming work. When a provider upgrade leaves resources in an inconsistent state, the impact can range from hours of debugging to real service disruptions.
Providers as critical as the underlying APIs
In his LinkedIn post, Gowie avoids turning the discussion into a simple attack on Cloudflare, but he does send a strong message to all vendors: organisations should treat their Terraform/OpenTofu provider with the same seriousness as their public APIs.
For many engineering teams, the provider is the primary interface to a service. It is how they create, modify and destroy resources, and how they keep infrastructure reproducible and auditable. If the provider is unreliable, the whole Infrastructure-as-Code (IaC) model becomes fragile.
Gowie contrasts the Cloudflare experience with providers that his team enjoys working with, such as those maintained by Datadog, GitHub or Spacelift. These, he says, are mature, well-designed and rarely cause trouble in day-to-day operations, enabling his company to deliver complex projects for clients without constant firefighting.
The underlying message to vendors is clear: if a company wants serious platforms built on top of its services, it must invest not only in great APIs but also in a robust, developer-friendly provider.
Developer experience is part of the product
For years, the conversation around cloud services focused on performance, feature sets and pricing. The rise of Terraform, OpenTofu and other IaC engines has shifted that attention toward developer experience.
A high-quality provider is not just one that exposes all available resources. It should also:
- Follow a predictable versioning policy, where minor and patch releases do not introduce compatibility-breaking changes.
- Provide clear error messages and high-quality documentation.
- Ship with migration guides and tooling when significant changes are required.
- Offer respectful, responsive communication in issue trackers and community channels.
When these elements are missing, the cost to DevOps teams increases dramatically: more time spent reverse-engineering behaviour, delaying updates out of fear, or maintaining old versions simply to avoid the risk of breaking production.
Cloudflare’s response and the path forward
Gowie later updated his post to include a response from a Cloudflare product manager, who acknowledged the feedback and indicated that improvements to the provider are in progress. Details are still limited, but the reaction suggests that the company is aware of the dissatisfaction within the IaC community.
For organisations that rely heavily on Cloudflare’s Terraform provider, the coming months will be important. Transparency about the roadmap, better testing and clearer communication around breaking changes will be essential to rebuild trust.
In the meantime, the incident serves as a reminder that tooling around a platform can strongly influence how it is perceived. A powerful service with a weak provider becomes harder to recommend for teams that automate everything through code.
What platform teams can do today
Until the situation improves — and as a general rule for any provider — infrastructure and platform teams can take several practical steps to reduce risk:
- Control update cadence
Avoid auto-upgrading to the latest provider version in critical environments. Use staging or sandbox environments to test upgrades before rolling them out to production. - Pin explicit versions
In Terraform or OpenTofu modules, specify exact or constrained versions (for example,~> 5.12) instead of allowing unbounded updates. This gives teams control over when to adopt new behaviour. - Back up state aggressively
Ensure that there are reliable, automated backups of the state file before attempting provider upgrades. If something goes wrong, rolling back becomes much safer. - Participate in the community
Reporting bugs, proposing improvements and voting on issues helps maintainers prioritise the most painful problems. Shared workarounds can also save others many hours. - Evaluate long-term options
If a provider consistently introduces instability, teams may need to reassess their architecture: from writing internal abstraction layers to, in extreme cases, considering alternative services that offer stronger IaC support.
Signs of a maturing IaC ecosystem
Beyond the specific case of Cloudflare, the reaction to Gowie’s post shows how much the IaC ecosystem has matured. Teams are no longer satisfied with “good enough” providers. They expect polished tools, solid versioning practices and high-quality support.
For vendors, this is both a challenge and an opportunity. Good providers don’t just reduce support tickets; they become a strategic advantage. Services that are easy to automate and integrate will always be more attractive to organisations that manage complex, multi-cloud or multi-region environments.
In 2025, having a solid API is only half the story. The companies that want to be at the centre of modern infrastructure stacks must treat their IaC providers as first-class products — with all the engineering, UX and support investment that implies.
Frequently Asked Questions
Why does the quality of a Terraform or OpenTofu provider matter so much?
Because the provider is the layer that turns declarative code into real API calls. If it behaves unpredictably or introduces breaking changes without warning, it can destabilise entire environments and erode confidence in Infrastructure as Code practices.
What are “breaking changes” in the context of a provider?
Breaking changes are modifications that cause previously valid configurations to fail or behave differently after an upgrade. When they appear in minor or patch versions, teams are forced to review code, edit state files and potentially rollback deployments — exactly what IaC is supposed to reduce.
How can teams assess whether a provider is trustworthy before adopting it at scale?
Useful signals include: activity and responsiveness on GitHub, frequency and clarity of releases, quality of the documentation and examples, whether the provider is maintained by the service owner, and feedback from other users in the community.
What best practices should vendors follow when maintaining their own providers?
Vendors should maintain clear versioning rules, avoid introducing breaking changes in minor releases, publish detailed changelogs and migration guides, thoroughly test new versions, and communicate openly with users through issues, forums and official channels.
