Terrateam charges per user, not per runner or workspace. This isn't a pricing gimmick, it's an architectural position that reflects what we believe about infrastructure automation. The unit of value in this space isn't CPU cycles or execution nodes, it's human collaboration mediated through version control. Every Terraform run originates from a developer proposing a change, a teammate reviewing it, and someone approving it to land in production. That pull request, that review flow, that human decision point is where governance actually happens, where security boundaries get enforced, where the audit trail matters. We price there because that's where the control plane lives, and we make the execution layer free because isolation shouldn't be a line item on your invoice.

Security architecture shouldn't cost extra.

The best practice for Terraform runner architecture is isolation. Separate runners per environment (development, staging, production), separate runners per team, separate runners per compliance boundary. This isn't controversial, it's standard security posture. You want blast radius containment, you want least-privilege execution, you want the ability to segment infrastructure operations by trust level. Now here's where the pricing model reveals its values. Most platforms charge per runner or per workspace, which means every time you follow that best practice (isolate another environment, segment another team), you pay more. They've created a financial incentive against doing security correctly.

We looked at that model and decided it was backwards. If your pricing punishes isolation, you're going to end up with customers who share runners across environments to save money, who consolidate workspaces to stay under tier limits, who make security decisions based on vendor pricing instead of actual threat models. That's not how infrastructure should work. So we made private runners free. Not "free tier with limits," not "included up to N," just structurally free. You can run one runner or a thousand runners, isolated by environment or team or compliance zone or whim, and the price doesn't change because we're not charging for execution nodes.

Compliance frameworks assume segmentation.

If you're in a regulated industry (finance, healthcare, defense, anything touching PCI or HIPAA or FedRAMP), you're required to segment execution environments by data classification or compliance scope. That's not optional. SOC 2 Type II audit controls expect it, ISO 27001 frameworks assume it, government compliance mandates demand it. Your Terraform runners handling production customer data cannot share an execution environment with your development sandbox, period. Under a per-runner pricing model, regulatory compliance becomes an escalating cost center. The more you comply, the more you pay. Under our model, compliance is architecturally encouraged. Need to isolate your FedRAMP workloads on dedicated runners? Go ahead. Need separate execution contexts for PCI-scoped infrastructure? That's what you should be doing anyway, and we're not going to charge you for it.

Pricing should map to collaboration, not traffic.

Teams scale by hiring engineers, not by provisioning runners. A 5-person infrastructure team becomes a 15-person infrastructure team by bringing on more people who write Terraform, review changes, and approve applies. That's the natural growth vector, more humans collaborating through pull requests. By pricing per user, costs scale linearly with the thing you're actually growing (your team size), not with the implementation details of how you've architected runner isolation. This also makes budgeting trivial. You know how many engineers have commit access to your repositories, multiply by the per-seat price, done. No variable costs based on number of runs (which penalizes CI automation maturity), no surprises based on runner proliferation (which penalizes security best practices), no scaling costs tied to workspace count (which penalizes monorepo structures).

Other platforms create pricing friction around things that should be encouraged. Per-run pricing makes you hesitant to automate drift detection or run speculative plans on every commit. Per-runner pricing makes you consolidate execution environments when you should be isolating them. Per-workspace pricing makes you architect around pricing tiers instead of around your actual infrastructure topology. We wanted to avoid all of that. Infrastructure decisions should be made on technical merit and security requirements, not on what keeps the monthly bill predictable.

Git is the control plane.

Terrateam is built on GitOps principles. Plans happen in pull request comments, approvals use your VCS review system, policies are enforced at the pull request level, audit trails map to Git history and PR activity. The entire control surface lives in your version control system because that's where your team already collaborates, that's where your RBAC is defined, that's where your SSO integrates, that's where your compliance auditors look when they need an operation timeline. Pricing by user aligns with this architecture, we're charging for access to the control plane (who can propose and approve infrastructure changes), not for the execution substrate (how many machines run Terraform).

By contrast, platforms that charge per runner or workspace introduce a separate control plane (their proprietary UI, their user management system, their audit logging) because they need to justify the pricing model. If you're paying per workspace, you interact with workspaces through the vendor's interface, not through your VCS. That abstraction layer breaks GitOps purity and adds operational overhead, you now have two sources of truth for who can do what, VCS permissions and vendor-specific RBAC. We collapsed that. If you have write access to the repository and you're part of your VCS organization, you can interact with Terrateam. Your permissions, your collaboration model, your audit surface all live in Git, where they belong.

Fair pricing encourages best practices.

The philosophical stance here is straightforward. Software pricing should encourage users to do things correctly, not to cut corners for cost savings. We don't meter runners because we want you to isolate execution environments aggressively, by team, by environment, by compliance boundary, by whatever axis makes sense for your security posture. We don't charge per workspace because we want you to structure your Terraform how it makes sense architecturally, monorepo or polyrepo, micro-workspaces or macro-modules, whatever fits your team's workflow. We don't charge per run because we want you to automate everything, drift detection on cron, speculative plans on every commit, validation checks in pre-commit hooks.

When pricing is decoupled from operational mechanics, you optimize for outcomes (safe infrastructure changes, fast feedback loops, complete audit trails) instead of for cost avoidance. That's the model we wanted. Charge for the collaboration surface (users), make the operational surface (runners, workspaces, runs) free, and let teams architect their infrastructure automation without financial friction.

What this looks like in practice.

A team of 10 engineers managing infrastructure across AWS, GCP, and Azure might run 30 isolated Terrateam runners (one per environment per cloud provider, plus dedicated runners for compliance-scoped workloads). Under a per-runner model, that's 30 billable units. Under our model, that's 10 billable units (the 10 engineers with repository access). The team with better isolation pays the same as the team with sloppy runner consolidation, which means there's no penalty for doing it right.

Similarly, a team running drift detection every hour, speculative plans on every commit, and validation checks in CI might generate 10,000 Terraform operations per month. Under a per-run model, that's a scaling cost problem. Under our model, it's free. Automate as aggressively as you want, we're not counting executions.

This isn't altruism. It's a bet that if we remove the financial friction around security isolation and automation maturity, teams will build better infrastructure, have fewer incidents, move faster, and stick with the platform because it actually helps them instead of fighting them on pricing.

The competitive position.

Most platforms charge per runner, per workspace, or per run, treating execution infrastructure as the billable primitive. That model works great for vendor revenue (every architectural improvement you make, every environment you isolate, every workspace you split, increases your bill), but it works terribly for customers who want to follow best practices. Whether it's tiered pricing based on workspaces, per-runner fees, or per-run charges, these models create the same perverse incentive to consolidate instead of isolate.

We took the opposite stance. Users are the control surface, that's where governance happens, that's what we charge for. Everything downstream (runners, workspaces, executions) is operationally metered for technical reasons (dependency tracking, lock management, concurrency control) but not financially metered because we don't want pricing to influence your architectural decisions. You should use as many runners as your security model demands, organize workspaces however your repository structure requires, and run as many operations as your automation maturity supports. None of that should show up on your invoice.

Open source changes the math.

The other piece of this is self-hosting. Terrateam's open-source core gives you the full platform, you can run it on your own infrastructure, bring your own compute, manage your own runners, and the only cost is what you're paying your cloud provider for the machines. We have a managed cloud offering for teams that prefer that operational model, but you're never locked into it. If our pricing doesn't work for you at scale, if you have specific compliance requirements that demand on-premises deployment, if you just prefer running your own infrastructure, the open-source version is a first-class citizen with feature parity.

This matters because it changes the negotiating position. You're not held hostage by vendor pricing because you can always self-host. We have to keep our managed offering competitively priced and genuinely valuable (better operational simplicity, better uptime, faster updates) or customers will just run it themselves. That's healthy tension. It keeps us honest, keeps the pricing fair, and ensures that the managed service is actually worth paying for instead of being a structural lock-in.

The values underneath.

Pricing is an architectural statement. It reveals what a company believes is valuable, what they want to encourage, what they're willing to penalize. When a platform charges per runner, they're saying execution infrastructure is the scarce resource, when they charge per workspace, they're saying organizational structure is the value driver. We charge per user because we believe the value in infrastructure automation is human collaboration mediated through version control, the ability for teams to propose changes safely, review them thoroughly, approve them confidently, and trace them completely. That happens at the Git layer, not at the execution layer.

Everything else (runners, workspaces, plans, applies) is operational substrate. It should be fast, reliable, isolated, and deterministic, but it shouldn't be a line item on your invoice because it's not where the actual governance lives. When you align pricing with the control plane (users collaborating through Git) and make the execution plane free (runners), you remove the financial friction from doing things correctly. Security isolation becomes the default, automation maturity becomes encouraged, and architectural decisions get made on technical merit instead of cost optimization.

That's the model we wanted. Charge for collaboration, make security free, and let teams build infrastructure the way it should be built.

Features

Learn More

Learn

Connect