Terrakube: running Terraform workflows from a shared web console

A console around the Terraform workflow, not a wrapper around the CLI

Terrakube describes itself as open source IaC automation and collaboration software, and the collaboration part is the interesting half. Terraform itself is a per-machine tool: a developer clones a repository, sets variables, runs a plan, and applies it. That works until a dozen teams share the same modules, the same cloud accounts and the same state files, and nobody can see what changed or who changed it.

Terrakube moves that workflow into a server. The feature list describes the Terraform workflow as something you can run from anywhere, anytime, with actions such as terraform apply, terraform plan and terraform destroy, plus the ability to manage variables and access the Terraform state files. The repository layout backs this up: there are separate directories for api, registry, executor, bindings, ui and openapi-spec, alongside docker-compose directories for deployment, telemetry-compose and dynamic-credential-setup.

The primary language is Java, with Spring Boot in the topic tags, and the whole thing runs on Kubernetes in the supported deployment paths. The audience implied by the feature set is a platform engineering team, not a lone developer.

One distinction worth holding onto: Terrakube does not replace Terraform or OpenTofu. It stores the code, drives the workflow, and keeps the artefacts.

Workspaces, organizations and tags are the access model

The organizational model is the core of the product. Organizations and Workspaces are used to manage infrastructure in a structured way, and Workspaces support Tags that let you group, organize and filter them.

That filtering capability is what makes the tool useful at scale. Once a workspace carries a tag for its team, its environment or its cost centre, you can select a set of workspaces for a bulk operation instead of clicking through each one. The feature list also mentions access control that assigns granular permissions to Workspaces, Modules, VCS and other resources.

Identity comes through Dex, an external identity provider that Terrakube uses for authentication. The documentation lists the providers it can sit in front of: Azure Active Directory, Amazon Cognito, GitHub, SAML and more. The stated point of Dex is that you can use your existing groups to assign permissions, so access follows the group membership you already maintain rather than a second set of accounts inside the tool.

The repository also has a dynamic-credential-setup directory, and the topic tags mention terraform-cloud and terraform-registry, so this sits in the same category as hosted Terraform platforms. The difference is ownership: this one runs on your own infrastructure.

Git providers are wired in, and the CLI still works

Version control integration is listed with named products: GitHub Cloud and Enterprise, GitLab EE and CE, Bitbucket and Azure DevOps, used to retrieve your terraform or opentofu code. That list is the practical answer to the question of where the code comes from, and covering both the enterprise and community editions of GitLab matters in regulated environments where the code cannot sit on a public SaaS.

The second half of that feature is more unusual. Terrakube supports both the remote backend and the cloud block, so you can run your workflow directly from the Terraform or OpenTofu CLI. In practice that means the CLI on a developer laptop and the web console operate on the same state and the same workspaces, rather than the CLI being cut off from the platform. For a team migrating in, that continuity matters more than the console itself.

The code that runs the workflow is isolated in the executor area, with an ephemeral-executor-config directory at the root, and there is a private registry area as well. The repository also contains a docs entry about requiring a saved plan in an apply template, which is the shape of an approval gate: the plan that was reviewed is the plan that gets applied.

Extensions are where compliance checks and cost estimates attach

The custom workflows feature is the most extensible part of the design. The documentation describes enhancing an IaC workflow with OPA, Infracost, or any other tool of your choice, using Terrakube extensions to integrate them, or building your own custom integration against the Terrakube API.

The stated purposes are compliance checks, cost estimates and security scans for Terraform projects. That is a meaningfully different axis from the rest of the product. Running a plan centrally is useful on its own, but the reason a platform team puts plans in one place is usually so that a policy gate, a price estimate and a scan run before anyone spends money or changes infrastructure.

There is also a private registry for publishing Terraform modules and providers privately, which addresses a related problem: sharing internal modules through a private registry rather than by copying directories or pointing at a shared drive.

The openapi-spec directory at the root and the bindings directory suggest the API is treated as a first-class surface, which is what makes the custom integration path realistic rather than aspirational. The telemetry-compose directory suggests the same telemetry stack can be run on its own.

Getting it running: Helm, Docker Compose, minikube, Codespaces

The project documentation lists several ways to get an instance, and the project documentation is explicit that the fastest route for testing is to install nothing locally at all: it points at opening the repository in GitHub Codespaces, described as a quick way to test Terrakube without having to install anything on your computer. There is also a .devcontainer directory and a devfile.yaml at the root for local development in a container, and the README links to a document for developing Terrakube locally using Dev Containers.

For deployment, the installation section lists a Helm install, a Docker Compose install, a minikube option for testing, and a Gitpod option. Note one wrinkle in the links themselves: the Helm entry points at a URL path that reads docker-compose, so the two installation guides are not cleanly separated in the current documentation. Follow the target pages rather than the label.

The complete documentation lives at docs.terrakube.io, and the project documentation points there for everything beyond the getting started pages. There is no single command in the documentation for a local install, so the concrete steps for a Helm or Docker Compose deployment live in those linked pages rather than in the project documentation itself.

Licensing, release cadence and the boundary of the tool

Terrakube is licensed under Apache-2.0, and the licence badge in the project documentation points at the LICENSE file. There is a second licensing question that is specific to this project: the README states that HashiCorp confirmed Terrakube is compatible with the new Terraform BSL License, with a link to a discussion in the project organisation. For organisations that have already assessed the Business Source License change, that compatibility confirmation is the relevant fact, and the discussion thread is where the detail sits.

Release activity is heavy and the versioning is pre-release. The recent tags are 2.34.0-beta.8 on 2026-10-10, 2.34.0-beta.7 on 2026-10-02 and 2.34.0-beta.6 on 2026-09-25. The last push was on 2026-10-20. A beta train on a two-week cadence means the product is moving fast, and pinning to a specific beta in a production deployment means planning for the next one.

The boundary of the tool is worth stating plainly. Terrakube does not supply modules, providers or cloud credentials, and it does not make the underlying plan correct. It stores code, sequences workflow, records state and attaches policy checks around it. A team that does not yet have a shared platform problem will find that it has gained a server, an identity provider and a workflow model to manage, and the value only appears when several people need to run the same infrastructure through the same door.

Editorial conclusion

Terrakube fits a platform team that has outgrown running Terraform by hand, where the same modules and variables are reused across teams and every apply needs a record, a permission check or a review step. It does not fit a single developer working in one repository, since it introduces a server, an identity provider and a workflow model to solve a coordination problem that does not exist yet. Before adopting it, read the deployment documents for Helm and Docker Compose on the docs site and confirm the Terraform BSL compatibility note, since that determines whether the tool fits your organisation's licensing rules.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. terrakube-io/terrakube on GitHub