HashiCorp Cloud Platform (HCP) recently started the final transition to RUM pricing. RUM pricing stands for Resources Under Management pricing, which in the context of HCP Terraform means you are charged based on the number of infrastructure resources Terraform manages.

My issue with RUM pricing is not that I want to run my own Terraform backend or database for governance reasons or some personal vanity project. The issue is that RUM pricing is fundamentally charging customers for tiny control-plane records that already live in AWS or Azure.

If I want to, I can store Terraform state in Azure Blob Storage and run Terraform using GitHub Actions with the community edition all day long. That is not a theoretical alternative—it is a well-understood, low-effort, and inexpensive setup. Do I get all the bells and whistles? No. But absent a sane pricing model that

When I compare that cost to RUM pricing, what becomes obvious is that I’m not paying for storage, compute, or execution. I’m paying for the fact that HCP Terraform tracks a large number of very small resources.

Those resources are the problem.

RUM Is a Proxy for Cloud Control-Plane Objects

When you strip away the abstraction, RUM pricing is charging you for how many individual cloud control-plane settings Terraform manages on your behalf. These are not all big things. The cloud is not just big beefy EC2 instances. We are talking small nuanced configuration like role assignments, policies, identity groups, DNS records, flags, permissions, and configuration switches.

Each one of these already exists as a row in AWS or Azure’s control-plane databases. Most of them cost nothing on your cloud bill. They are necessary for correctness, security, and modularity, but they are not expensive.

Under RUM pricing, each of these tiny objects becomes a recurring cost. That means the pricing model directly penalizes customers for writing precise Terraform and managing infrastructure at a fine level of detail.

The Comparison Customers Actually Make

From a customer’s perspective, the comparison is not “HCP Terraform versus running my own multi-tenant Terraform-as-a-Service offering.” The comparison is:

  • Azure Blob Storage for state
  • GitHub Actions for plan and apply

That combination already solves the core Terraform workflow. It scales, it’s cheap, and it’s priced on actual consumption: storage used and minutes of compute.

When RUM pricing exceeds that baseline, the question becomes unavoidable: why am I paying extra for someone else to count how many cloud resources I manage?

At that point, RUM feels less like a pricing model and more like a surcharge for using Terraform thoroughly.

Can HCP Terraform do more? Sure, those extra things (e.g., no-code provisioning, generating module tests, module deprecation, module revocation, team notifications and change requests, paywall continuous validation, ephemeral workspaces, versioned policy sets, policy as code policies) should just increase my consumption–not hidden behind a paywall.

Small Resources Break the Model

RUM pricing only holds together if most managed resources are large and expensive. In practice, the opposite is true. Most Terraform resources represent small, zero-cost control-plane objects. An Entra ID group costs nothing in Azure. An IAM policy costs nothing in AWS. A DNS record costs effectively nothing. Yet under RUM pricing, each of these carries the same recurring fee as managing something that actually costs money.

This leads to a perverse outcome: the better your Terraform hygiene, the more you pay. Modular code, fine-grained permissions, and explicit configuration all increase RUM counts without increasing real-world cost or operational burden.

That is where the negative reaction comes from. Customers are not objecting to paying for value—they are objecting to paying for granularity.

Why Consumption-Based Pricing Fits Terraform Better

What customers are asking for is not free features. They are asking for pricing tied to things that actually cost the platform money.

Those things are straightforward:

  • State storage size
  • Compute and memory used to run Terraform
  • Frequency of plans, applies, drift detection, and policy evaluation

This is why GitHub Actions works as a pricing model. You pay for minutes and storage. If you run Terraform often, you pay more. If you have lots of static infrastructure that rarely changes, you pay very little.

That aligns incentives cleanly. Customers can choose how often to run validation and drift detection. The platform incurs cost when work is done and gets paid when cost is incurred.

RUM breaks that alignment by charging continuously for resources that may never change and cost nothing to exist.

Feature Paywalls Miss the Point

Paywalling features like drift detection, policy as code, or continuous validation makes even less sense in this context. These features naturally increase consumption. That is how they should be monetized.

If a customer enables drift detection monthly instead of daily, that should be reflected in usage. If they enable it at all, it should be available—because the cost is already captured by compute consumption.

Under this model, there is no need to bundle features into tiers or force customers to pay for them across all workloads. Different workspaces have different usage patterns, and pricing should reflect that reality.

How to implement a Rational Freemium Model

These are the features that are currently behind the paywall for the Standard and Premium tiers. Where a feature only exists at the Premium tier, I’ve indicated it in parentheses so the format reads as Standard Feature (Premium Feature).

What’s important here is not whether these features are valuable—they clearly are—but how they are monetized. Today, access to many of these capabilities is gated regardless of how often they are used, how much compute they consume, or whether they generate any meaningful ongoing cost at all. That creates a mismatch between customer value, platform cost, and pricing.

  • Module deprecation (Module revocation)
  • Team notifications & change requests
  • No-code provisioning
  • Generated module tests
  • Waypoint templates
  • Waypoint add-ons
  • Audit logging
  • Drift detection
  • Continuous Validation
  • Ephemeral workspaces
  • Policy as code (Sentinel and OPA) - Unlimited
  • Versioned Policy Sets
  • Run Tasks - Unlimited
  • Run Tasks: Mandatory enforcement - Unlimited
  • Audit Trails
  • ServiceNow Integrations
  • Concurrency Max 10 (200)
  • Self-Hosted Agents 10 (300)
  • (Stacks Custom Deployment Groups)

Most of these features do not incur continuous cost simply by existing. Their cost is driven almost entirely by execution: how often Terraform runs, how frequently policies are evaluated, how much drift detection is performed, or how many events are generated. In other words, they are natural candidates for consumption-based pricing rather than tier-based access control.

Below is my take on how these features could be monetized in a way that makes them accessible to all customers, aligns cost with actual usage, and remains profitable for HashiCorp. The goal is not to eliminate pricing, but to move it away from artificial feature gates and toward the real drivers of cost: storage, compute, execution frequency, and capacity.

Feature What It Actually Does Primary Cost Driver Pricing Model Rationale
Module Deprecation / Module Revocation Marks modules as deprecated or revoked and prevents or warns on future use Metadata storage, light validation at plan time Consumption Essentially metadata plus occasional checks; no reason to gate access.
Team Notifications & Change Requests Sends notifications and manages approval workflows around runs Event handling, messaging, minimal compute Consumption Cost scales with number of runs and events.
No-Code Provisioning UI-driven execution of pre-defined Terraform workflows Terraform runs and UI interactions Consumption Cost is in execution, not access.
Generated Module Tests Automatically creates and runs tests for Terraform modules Compute time for test execution Consumption Clear compute-driven cost.
Waypoint Templates Predefined application deployment templates Storage and occasional execution Consumption Mostly static assets with optional execution.
Waypoint Add-ons Adds auxiliary services to Waypoint deployments Deployment execution and integration calls Consumption Directly tied to execution and runtime usage.
Audit Logging Records who did what and when Storage and write throughput Consumption Storage-based pricing fits naturally.
Drift Detection Periodic Terraform plans to detect out-of-band changes Scheduled compute runs Consumption Frequency directly drives cost.
Continuous Validation Repeated policy and state validation over time Compute and policy evaluation Consumption Cost exists only when validation runs.
Ephemeral Workspaces Short-lived workspaces for testing or previews Short-term storage and compute Consumption Ephemeral by nature; aligns with per-run pricing.
Policy as Code (Sentinel & OPA) – Unlimited Evaluates policies during Terraform runs CPU time per policy evaluation Consumption Policies should not be capped; charge on execution.
Versioned Policy Sets Maintains multiple versions of policies Metadata storage and policy execution Consumption Versioning is cheap; execution drives cost.
Run Tasks – Unlimited External integrations triggered during runs External calls and orchestration Consumption Meter per execution.
Run Tasks: Mandatory Enforcement – Unlimited Blocks runs unless tasks succeed Same as Run Tasks Consumption Enforcement changes behavior, not cost structure.
Audit Trails End-to-end traceability of actions across time Storage and indexing Consumption Scales cleanly with activity.
Private VCS Access Private connectivity to version control systems Network egress + auth handling Paywall Capacity and support overhead justify tiering.
Private Policy Enforcement Enforces policies within private networks Policy evaluation Paywall Capacity and support overhead justify tiering.
Private Run Tasks Executes run tasks in private environments Task execution Paywall Capacity and support overhead justify tiering.
Hold Your Own Key (HYOK) Customer-managed encryption keys Key operations Paywall Legitimately tied to compliance requirements, not usage.
ServiceNow Integrations Creates or updates tickets during Terraform runs API calls and event processing Paywall External calls per run are a clean meter.
Concurrency Limits (Max 10 / 200) Limits parallel Terraform runs Peak compute capacity Paywall This is reserving capacity, not usage.
Self-Hosted Agents (10 / 300) Allows customer-managed execution agents Control-plane metadata and coordination Paywall Capacity and support overhead justify tiering.
Stacks Custom Deployment Groups Groups and orchestrates multi-stack deployments Orchestration and execution Consumption Cost scales with orchestration activity.

A particularly bad example is Stacks Custom Deployment Groups being paywalled. Deployment groups are purely a control-plane abstraction. Their real cost shows up only when they trigger Terraform runs. If monetized through consumption instead, deployment groups would increase platform usage, not reduce it. For example, I could safely enable -auto-approve=true for development and test workloads while keeping production gated. That would encourage more frequent applies, more plans, and more overall execution—exactly the kind of behavior a consumption model should incentivize.

By paywalling deployment groups, the platform discourages customers from structuring environments in ways that would actually drive more compute consumption.

Conclusion

RUM pricing fails because it charges customers for the existence of tiny cloud control-plane objects—objects that already exist, cost nothing, and are fundamental to writing good Terraform.

Customers can already store state cheaply in blob storage and run Terraform using consumption-based CI systems. When RUM pricing exceeds that baseline, it stops being defensible.

Terraform users are not trying to avoid paying for execution, storage, or real platform costs. They are pushing back on a model that turns careful infrastructure design into a recurring tax.

A pricing model based on storage and execution would match how Terraform is actually used. RUM does not.