Webhooks

Manage Workspaces permission is required to perform this action, please check Team Management for more info.

Webhooks let a Version Control workflow workspace react automatically to activity in its git repository: kicking off a plan/apply job on a push, or posting plan and apply results as comments on a pull request. This page covers the Webhook tab inside a workspace's settings. For connecting Terrakube to your VCS account in the first place, see VCS Providers.

Enabling the webhook

Open a workspace, go to Settings > Webhook, and turn on Enable VCS Webhook?. Once enabled, Terrakube registers a webhook with your VCS provider and shows its remote ID.

On GitHub repositories you can optionally click Migrate to Shared Webhook to consolidate the webhooks for every workspace pointed at the same repository into a single shared webhook, instead of one per workspace. This is experimental; Revert switches a workspace back to its own per-workspace webhook.

Webhook events

Each row in the events table matches a specific kind of repository activity to a template:

Field	Description
Priority	When more than one event row of the same type could match a payload, Terrakube evaluates them in ascending priority order and uses the first one whose branch and file filters match.
Event	Push, Pull Request, or Release. See provider support below — not every VCS supports every event type.
Branch/release	Comma-separated list of branch or release names, matched as a regex against the branch/release in the payload.
Path Type	Pattern for simple wildcards like terraform/* or modules/**, or Regex for full regular-expression matching against changed files. Branch/release matching always uses regex regardless of this setting.
File	The pattern or regex list (depending on Path Type) that changed files must match for the job to run. Useful for monorepos so unrelated changes don't trigger a run.
Template	The Templates to run when this event matches.

Posting plan and apply results on pull requests

For Pull Request events, two independent switches control an Atlantis/TFE-style PR comment workflow:

Toggle	Effect
Post Plan on PR	Terrakube posts the plan output as a comment on the pull request, and accepts terrakube plan PR comments to re-run the plan.
Allow Apply via PR Comment	Accepts terrakube apply PR comments to run the workspace's default template with auto-apply. Only selectable once Post Plan on PR is enabled.

If Allow Apply via PR Comment is off, the plan comment shows a notice instead of the apply instructions, and a terrakube apply comment gets a reply explaining apply is disabled rather than being silently ignored:

Ask a workspace admin to enable Allow Apply via PR Comment in the Webhook settings, or apply the plan from the Terrakube UI.

What a plan comment looks like:

• A header with the workspace name, status, and a link back to the run in the Terrakube UI.

• A status icon (✅ / ❌ / ⚠️) and a one-line summary (e.g. Plan: 2 to add, 0 to change, 0 to destroy. or No changes.).

• The full plan output in a collapsible, diff-highlighted block.

• A footer inviting terrakube apply (only when enabled) and terrakube plan to re-run.

Replans update the existing comment. Pushing new commits to the same PR edits the existing plan comment in place instead of posting a new one every time — if the edit fails (for example the original comment was deleted), Terrakube falls back to posting a new comment. Apply results always post as their own separate comment, so the apply history is never overwritten.

Command acknowledgment. As soon as Terrakube recognizes a terrakube plan or terrakube apply comment, it reacts to that comment with 👀 so you know it was seen. Once the triggered job finishes, the reaction updates to ✅ (success) or ❌ (failure). Bitbucket has no comment-reaction API, so acknowledgment is a no-op there — Bitbucket users still get the plan/apply result comment itself.

GitHub pull request with a Terrakube plan comment

GitLab merge request with a Terrakube plan comment

Provider support

Provider	Push	Pull Request	Release	Post Plan on PR / Apply via PR Comment
GitHub	✅	✅	✅	✅ (with 👀→✅/❌ reactions)
GitHub Enterprise	✅	✅	✅	✅ (with 👀→✅/❌ reactions)
GitLab / GitLab EE/CE	✅	✅	✅	✅ (with 👀→✅/❌ award emoji)
Bitbucket	✅	✅	✅	✅ (no reactions — no comment-reaction API)
Azure DevOps	✅	✅	–	Not yet supported
SSH	–	–	–	–

Azure DevOps triggers push and pull-request jobs via service hooks (or outbound polling on private networks — see Azure DevOps), but the PR comment plan/apply workflow above is currently only available for GitHub, GitLab, and Bitbucket. SSH-based repositories have no webhook support at all; runs must be triggered manually, via the API, or on a schedule.