Kevra Infra Now Runs Terrakube 2.33: What's New for Terraform and OpenTofu Teams

Kevra Infra is managed Terrakube. As of October 23, 2026, it runs Terrakube 2.33.3 in production, up from 2.30.2. Upgrades are handled by Kevra, so there is nothing for you to install.

The jump covers three upstream minor releases, 2.31 through 2.33, and a long list of changes. This post picks the ones that matter most to a team that runs Terraform or OpenTofu every day. Each section links to the upstream release notes it comes from, and the credit for all of it goes to the Terrakube community.

Plans posted on pull requests

Terrakube 2.31.0 added a pull request workflow modeled on Atlantis, and 2.33.0 reworked the plan and apply comments it posts (2.31.0, 2.33.0). In 2.33.3 there are two switches on the pull_request event in a workspace's webhook settings:

• Post Plan on PR posts a plan comment on every pull request for that workspace. Reviewers can re-run the plan by commenting terrakube plan.
• Allow Apply via PR Comment lets someone apply from the pull request by commenting terrakube apply. It needs Post Plan on PR, and the workspace stays locked while that apply runs.

Both are off by default. PR comments work with GitHub, GitLab and Bitbucket connections, and the connection needs permission to write to pull requests. Since 2.33.0 the commit status on the pull request also includes a short plan or apply summary, and VCS permission errors for webhooks and PR comments are reported instead of failing silently. Before you turn on apply via comment, check who can comment on the repository.

One webhook per repository

If several workspaces point at the same repository, for example one per environment, each one registers its own webhook with your Git provider. 2.31.0 introduced shared repository-level webhooks as an experimental option, and 2.33.0 added GitLab support and made delivery scale to large shared webhooks (2.31.0, 2.33.0).

In the workspace webhook settings, Migrate to Shared Webhook replaces the per-workspace webhook with a single one for the repository, and Revert goes back. In 2.33.3 the option shows up for GitHub and GitLab connections and is still labeled experimental, so try it on a low-risk repository first.

Access at the project level

Terrakube already had organization teams and workspace access with predefined roles: admin, write, plan, read and custom. 2.32.0 adds project management pages and project-level team permissions, with the same roles and inline role editing on the project's access tab (2.32.0). You grant a team access once on the project instead of on every workspace in it.

The useful part is the split between planning and applying. In Terrakube's role model, the plan role can queue plans but cannot apply, while write and admin can also approve and apply. The custom role exposes the individual flags, with plan and approve as separate permissions. A team can see what a change would do across a project's workspaces without being able to apply it. 2.33.0 also reworked the workspace access screen (2.33.0).

Run notifications in Slack, Teams or a webhook

2.33.0 adds notifications for job status changes (2.33.0). You create one in the organization settings, where it applies to every workspace, or in a single workspace's settings. Each notification has one destination:

• Slack or Microsoft Teams, through the incoming webhook URL of a channel.
• A generic webhook, with an optional signing secret so your receiver can verify the payload.

You pick the job statuses that trigger it, such as waiting for approval, completed, failed or rejected, and you can limit it to specific templates. Each notification keeps a delivery history. 2.33.1 then stopped false failure alerts for runs that recover and complete (2.33.1).

Module versions that follow SemVer

The private registry now publishes module versions in canonical SemVer form and validates version formats (2.33.0). A Git tag such as v1.4.0 is published as 1.4.0, the original tag is kept, tags that are not valid SemVer are not published as versions, and a module can hold each version only once. The UI also stops showing a double v prefix on versions. 2.33.1 fixed version path resolution for module versions without a Git tag (2.33.1).

Target and replace from the UI

The New Run dialog has two new fields under its additional planning options: target resources, which limits the plan to the addresses you list and their dependencies, and replace resources, which forces replacement of those addresses on the next apply (2.33.0). It is handy for recreating one broken resource without touching your code.

Faster and sturdier as you grow

• Database indexes. 2.32.0 added missing indexes on foreign-key columns and removed an N+1 query from the Terraform Cloud compatible workspace list endpoint (2.32.0).
• More than 500 workspaces. The API capped workspace collections at 500 rows. 2.33.2 lifts that cap (2.33.2).
• Longer VCS tokens. 2.33.0 widened the columns for VCS OAuth access and refresh tokens and for GitHub App tokens, so oversized OAuth tokens and the new GitHub installation token format fit (2.33.0).
• Job soft delete. Deleting a job now marks it as deleted and hides it, instead of removing the record (2.33.0).

What you need to do

Nothing for the upgrade itself. Your CLI workflow stays the same: the same cloud block, terraform login and remote plans. To use the new features, open your organization or workspace settings and turn on the ones you want. Kevra-specific guides are in the Kevra Infra docs.

New to Kevra Infra? Start with what hosted Terrakube is and when it fits, or read about HCP Terraform's free tier limits if you are moving from there.

Comparing options? See HCP Terraform alternatives, Terrakube vs Atlantis and the step-by-step migration from HCP Terraform to Terrakube.

Sources: Terrakube release notes for 2.31.0, 2.32.0, 2.33.0, 2.33.1, 2.33.2 and 2.33.3, and the Terrakube source at tag 2.33.3, checked October 23, 2026.