Hosted Terrakube with Kevra Infra: What It Is and When to Use It

Most Terraform and OpenTofu teams reach the same point. Running plans from laptops stops working, and you need remote state with locking, plans triggered from pull requests, a private module registry and some policy checks. HCP Terraform does all of that, but its Free tier now stops at 500 managed resources and paid plans bill per resource, per hour (HashiCorp docs, checked October 9, 2026). Running an open-source platform yourself avoids the meter but adds servers, upgrades and on-call.

Hosted Terrakube sits between the two. Terrakube is an open-source platform that does what HCP Terraform does for Terraform and OpenTofu. Hosted Terrakube means someone else installs it, upgrades it and keeps it running, and you get a URL and a login.

This guide covers what Terrakube is, what changes when it is hosted, what you get, when it fits, when it does not, and how to start.

What Terrakube is

Terrakube describes itself as "open source IaC automation and collaboration software". It is licensed under Apache-2.0 and maintained by the Terrakube community on GitHub.

Terrakube is not a fork of Terraform. It is the platform around the CLI: it stores state, queues and runs plans and applies, connects to your Git repositories and hosts a private registry. Underneath, it runs Terraform or OpenTofu.

The part that matters most for adoption: Terrakube supports both the remote backend and the cloud block. Your configuration points at a Terrakube hostname instead of app.terraform.io, you run terraform login once, and terraform plan runs remotely with the output streamed to your terminal, the same way it does with HCP Terraform (Terrakube CLI-driven workflow).

Credit where it is due: Terrakube is built by its open-source community. A hosting provider, Kevra included, runs it; it does not own it.

What "hosted" changes: who runs what

The software is the same either way. What changes is who does the work around it.

Sources: Terrakube architecture, Terrakube deployment, HCP Terraform plans, Kevra Infra, all checked October 9, 2026.

The self-hosted column is not a criticism. Terrakube's components are standard and well documented. The point is that every one of them is something to patch, monitor and restore. If your team already runs Kubernetes, a database and object storage with care, self-hosting is a fair choice. If it does not, that is the work a hosted service takes on.

What you get on hosted Terrakube

If you use HCP Terraform today, most of what you rely on has a Terrakube equivalent:

Source: Terrakube README and docs.terrakube.io, checked October 9, 2026.

Terrakube also lets you build your own job flows with templates. Its docs show two useful ones:

• Cost estimation with Infracost, run after the plan, which can stop a job if the estimate passes a limit you set (needs an Infracost API key) (Terrakube cost estimation).
• Drift detection, a template that runs a plan on a schedule, counts planned changes and posts to Slack if anything drifted (Terrakube drift detection).

Both are templates you configure, not switches you flip. Kevra Infra lists cost estimation before apply and drift detection with scheduled checks among its policy features (Kevra Infra).

One honest difference: Sentinel is HashiCorp's proprietary policy language, and Terrakube's policy docs cover OPA only (Terrakube OPA). If you have Sentinel policies, plan time to rewrite them in Rego.

When hosted Terrakube is a good fit

You are close to HCP Terraform's 500-resource Free cap. Five hundred managed resources go quickly once every security group rule and DNS record counts. We wrote a separate guide on HCP Terraform's free tier limits, including two commands to estimate where you stand.

You are moving to OpenTofu. Terrakube runs Terraform or OpenTofu, so you can switch tools without switching platforms.

You want a bill that does not move with your resource count. A per-resource-hour meter means short-lived preview environments and growth both show up on the invoice. A flat plan price does not.

You do not want to own the platform. If nobody on the team wants to be on call for the thing that runs your infrastructure changes, hand it off.

When it is not

You depend on Sentinel or HashiCorp-only features. Staying on HCP Terraform, on a paid plan if needed, is the least disruptive path.

You need it inside your own network. If your rules require your own VPC, a region outside the US or an air-gapped setup, self-host Terrakube with its Helm chart.

You already run Terrakube well. If it is upgraded, backed up and boring, you have already done the hard part. Keep it.

You are under 500 resources and expect to stay there. HCP Terraform Free costs nothing. Revisit when you get close.

Getting started

The flow is the same on any Terrakube instance. Create an organization and a workspace in the UI, then add a cloud block to your configuration (Terraform 1.1 or later). Replace the hostname with the one for your Kevra Infra instance:

terraform {
  cloud {
    hostname     = "<your-kevra-infra-hostname>"
    organization = "your-org"

    workspaces {
      name = "your-workspace"
    }
  }
}

Then log in, initialize and plan:

terraform login <your-kevra-infra-hostname>
terraform init
terraform plan

The plan runs on Terrakube and streams back to your terminal.

To trigger plans from pull requests instead, connect your Git provider in the organization settings and pick a VCS workflow for the workspace (Terrakube VCS providers). Kevra-specific guides are in the Kevra Infra docs.

Moving existing workspaces

Terrakube's docs describe two ways to move from HCP Terraform or Terraform Enterprise (Terrakube migration guide):

1. Workspaces Importer. A wizard that takes your Terraform Cloud API key and copies "name, description, Terraform version, execution mode, variables, tags and the current state". Connect your VCS provider first for VCS-driven workspaces, and run it once per workflow type.
2. The CLI, one workspace at a time. Change the cloud block to the Terrakube hostname, run terraform login, then terraform init -migrate-state. This moves state only, so recreate variables yourself.

Either way, run terraform plan after the move. No changes means the state arrived intact. The CLI path is covered step by step in our guide to HCP Terraform's free tier limits.

Kevra Infra: hosted Terrakube at a flat price

Kevra Infra is Terrakube, run by Kevra as a managed service.

Hosted in the United States. Annual billing gives two months free. Want to try it before you subscribe? Write to contact@kevra.io and we will set up a trial. Full plan details are on the Kevra Infra pricing section.

We handle hosting, upgrades and uptime. It is the same open-source Terrakube, and the state it stores is standard Terraform state.

FAQ

Is Terrakube free?

The software is. Terrakube is open source under Apache-2.0, and you can run it yourself at no license cost. You pay for servers and your team's time. A hosted service like Kevra Infra charges for running it.

Is Terrakube a fork of Terraform?

No. Terrakube is the automation and collaboration platform around the CLI. It runs Terraform or OpenTofu to do the actual plans and applies.

Does hosted Terrakube support OpenTofu?

Yes. Terrakube runs the Terraform or OpenTofu workflow (Terrakube on GitHub), and Kevra Infra runs OpenTofu and Terraform code.

How is it different from HCP Terraform?

Both give you remote state, VCS-driven runs, a private registry and policy checks. HCP Terraform is HashiCorp's product, with Sentinel and per-resource billing above the Free tier's 500 managed resources. Terrakube is open source, uses OPA for policies and runs Terraform or OpenTofu. Hosted Terrakube on Kevra Infra is a flat monthly price per plan.