Skip to main content

Protecting Deployment Branches

A deployment branch policy restricts which branches can deploy to protected environments in a workspace. It turns the convention "publish only from the reviewed target branch" into a rule the platform enforces, rather than something each developer has to remember before selecting Publish.

Before you begin

  • You need permission to manage the deployment branch policy for the workspace. Without it, the page reports You do not have permission to manage deployment branch policy for this workspace.
  • A workspace must be selected. The policy is per workspace, not per application.

Setting the policy

  1. Select Settings in the left sidebar.
  2. Select Workspace > General, then select the Governance tab.
  3. Find Protected deployment branches.
  4. Turn on the switch beside the description to enforce the policy for this workspace's protected environments.
  5. In Allowed branch patterns, enter one pattern per line.
  6. Select Save.

Writing branch patterns

Patterns are matched against branch names, and matching is case-sensitive. A leading refs/heads/ is removed for you.

WildcardMatches
*One path segment
**One or more nested segments

For example:

main
release/*
release/**

release/* allows release/2026-09. release/** also allows release/2026-09/hotfix.

Constraints the platform enforces when you save:

  • At least one pattern is required — Add at least one allowed branch pattern.
  • At most 100 patterns per policy — A policy can contain at most 100 branch patterns.
  • * and ** on their own are rejected — A protected deployment policy cannot allow every branch. A policy that allows every branch is not a protection.
  • A pattern cannot start or end with /, contain ***, or contain characters that are invalid in a Git reference. An offending pattern is reported as Invalid branch pattern: <pattern>.

How policies combine

A workspace policy inherits the organization and global rules above it. It can narrow those rules but cannot allow a branch that a parent rule rejects — so tightening at the workspace level always works, and loosening does not.

The Development environment stays unrestricted unless it is marked protected. This is deliberate: developers keep publishing feature branches to Development for validation, while the branches that reach protected environments stay controlled.

How you know it worked

Koodisi confirms with Deployment branch policy saved. From then on, deployments to the workspace's protected environments are restricted to branches matching your patterns.

When you deploy, the deployment records the Git source it came from — Branch, the commit, Repository, and Deployed by — so you can confirm afterwards which branch a running deployment was published from.

When it does not work

SymptomCauseWhat to do
Select a workspace to edit its deployment policy.No workspace is selected.Select a workspace, then reopen the Governance tab.
You do not have permission to manage deployment branch policy for this workspace.Your role does not include managing this policy.Ask a workspace administrator to set it.
Could not load the deployment branch policy for this workspace.The saved policy could not be read. Koodisi shows the error rather than presenting a stale policy as current.Select Retry.
The policy changed or could not be saved. Reload and try again.Someone else changed the policy while you were editing it.Reload the page, read the current policy, and reapply your change.
Save stays unavailableNothing has changed since the policy was loaded.Edit a pattern or the switch first.
A branch you expected to allow is still rejectedAn organization or global rule above this workspace rejects it, and a workspace policy cannot widen a parent rule.Have the parent policy changed, or deploy from a branch the parent rule allows.