When the HashiCorp BSL licence change landed in August 2023, we thought "HashiCorp won't do anything too aggressive - they need the community too much."

I was wrong. Fast forward to today: IBM owns HashiCorp for $6.4 billion, the HCP Terraform free tier sunsets on March 31 2026, the Resources Under Management (RUM) pricing model has replaced the predictable per-seat model, and the cost estimation features that used to be table stakes have been quietly removed from standard tiers.

If your team is still on HCP Terraform's free tier, you have very little runway before that decision gets made for you.

But this post is not a vent about IBM. It is about something more useful: there is a specific and time-limited set of conditions right now that make this the best moment in years to rethink your IaC and infrastructure design workflow end-to-end - not just swap a remote backend.

What actually changed, precisely

The August 2023 BSL change: Terraform can no longer be freely used in certain commercial contexts - specifically in products that compete directly with HashiCorp's offerings. This spawned the OpenTofu fork under the Linux Foundation.

The IBM acquisition completed the picture. HashiCorp as a community-first company is not the entity you are now transacting with. IBM is a $60 billion enterprise software company optimising for enterprise revenue. The trajectory of HCP Terraform pricing from here is predictable, and it does not favour small teams.

The RUM model charges $0.10–$0.99 per managed resource per month. For a typical Series B AWS environment with a few hundred managed resources across environments, this compounds non-linearly as infrastructure scales - the opposite of what you want from toolchain cost when your AWS bill is also scaling.

The landscape of alternatives

OpenTofu - The most obvious move for preserving your HCL investment with minimal disruption. Apache 2.0, under Linux Foundation governance, broadly compatible with Terraform. Does not solve any underlying workflow problems - you are still writing HCL, still running applies without pre-deployment cost visibility. Free.

Scalr - Worth a look specifically for its pricing model: meaningful free tier with all features included, paid from ~$99/month. Explicitly positioned as a Terraform Cloud drop-in. Best choice if minimal disruption is the only goal.

Spacelift / env0 - Mature IaC orchestration platforms with robust remote state management, CI/CD integration, and policy enforcement. Both adding AI features. Serious options for teams with deep Terraform investment and enterprise requirements. $349–$399/month entry.

Pulumi - A more fundamental change: infrastructure in TypeScript, Python, or Go instead of HCL. $98.5M raised, over half the Fortune 50 as customers. If your team is already comfortable with TypeScript, the cognitive load is lower than it sounds. Free for individuals.

None of these platforms address the core workflow problem: the absence of pre-deployment validation. You still design, write IaC, deploy, and then discover whether your architecture handles load. The feedback loop is still post-deployment.

The workflow problem nobody talks about enough

Before we get into what to switch to, name the underlying problem clearly - because it shapes how to evaluate alternatives.

My current workflow - and yours probably looks similar - involves at minimum four disconnected tools for any significant infrastructure decision:

1. A diagramming tool (draw.io, Lucidchart) for the design conversation
2. The AWS Pricing Calculator to manually estimate cost - static, single-traffic-level, rebuilt from scratch every time the design changes
3. Terraform / CDK for the IaC that implements the design - often diverging from the diagram because the diagram was decorative
4. A post-deployment load testing tool (k6, Gatling, JMeter) to find out whether the architecture handles the traffic it was designed for - which requires deployed infrastructure

The fundamental absurdity of step 4: we are spending real AWS dollars to provision real infrastructure to discover whether our design was correct. When it is not - wrong concurrency limit, missing circuit breaker, absent CloudFront layer - we fix it after the fact, under time pressure.

The workflow change I made

Six weeks ago, someone sent me a link to pinpole with the note "this is weird but try it." I tried it. It is the most significant change to my infrastructure design workflow in several years.

pinpole is a browser-based canvas: drag AWS services from a palette, wire them, configure each service to reflect your actual intended configuration, run a traffic simulation against the design before any infrastructure exists. Spike from 300 RPS to 3,000 RPS against a Route 53 → API Gateway → Lambda → DynamoDB topology. Watch Lambda concurrency saturation in real time. Watch API Gateway throttling. Watch estimated monthly cost update live as the simulation runs. All in a browser tab. No AWS account required. No provisioned resources.

The first simulation I ran surfaced five findings in under two minutes. CloudFront absent. Lambda provisioned concurrency not configured (showing as cold-start spikes under the Spike pattern). Circuit breaker pattern missing on DynamoDB calls. I accepted the CloudFront recommendation - it was applied to the canvas automatically, the simulation reran, API Gateway RPS dropped, estimated cost reduced.

The workflow that emerged:

1. Design on pinpole canvas
   ↓
2. Spike simulation at anticipated peak - apply AI recommendations
   ↓
3. Export to Terraform from canvas state (native IaC export)
   ↓
4. Commit to source control → standard IaC pipeline
   ↓
5. Deploy with validated cost and performance expectations

pinpole is not a Terraform replacement. It is the design-time layer that sits before it. The HCP Terraform disruption happens to have created the right moment to add that layer, because teams are already revisiting their toolchain.