We're in closed beta. Sign up for early access — founding pricing locks in at signup.Sign up for early access
Control who can push to your default branch and what has to happen before a pull request can merge.
Every repository's default branch has one of three protection levels, set from the repository's Settings → Branch protection section:
For organization repositories left at None, the settings page recommends enabling protection — it's the one level where UnityFreak surfaces an explicit nudge.
Required approving reviews sets how many approvals a pull request needs before it can merge — 0 disables review requirements entirely. Reviewers can't approve their own pull requests, so this number always has to be satisfied by someone else.
Dismiss stale approvals, when enabled, means an approval only counts if it was given for the pull request's current head commit — pushing a new commit after someone approves clears that approval, so reviewers are always signing off on what's actually about to merge, not an earlier version of the diff.
Both of these are independent toggles from the protection level above — you can require approvals whether or not you also require pull requests for direct pushes (though requiring approvals only has an effect once pull requests are actually the way changes land).
With Require code owner approval enabled, every CODEOWNERS rule matching a changed file needs an approval from one of its owners before the pull request can merge — on top of any general required-approvals count.
Every @username entry in your CODEOWNERS file has to resolve to an eligible reviewer — a collaborator, an organization member, or the repository owner. An entry that doesn't resolve (a typo, or someone who's since lost access) is silently skipped for review-request purposes rather than blocking the sync, but the repository's Branch protection section surfaces a warning listing exactly which usernames didn't resolve and which patterns they were meant to cover, so the gap doesn't stay invisible.
Require status checks to pass blocks merging a pull request into the default branch until required checks pass. If you don't name any specific checks, merging is blocked until at least one commit status is reported and every reported status is green; naming specific check contexts narrows that down to only those checks mattering for merge.
UnityFreak doesn't run CI itself — external CI reports results by posting to a commit-status API using an API key with the repo:write scope:
curl -X POST https://unityfreak.com/api/v1/repos/{owner}/{repo}/statuses/$COMMIT_SHA \
-H "X-API-Key: $UNITYFREAK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"state":"success","context":"build","targetUrl":"https://ci.example.com/run/123"}'Valid state values are pending, success, failure, and error. The context is the check's name — the same string you'd add as a required status check context above to make that specific check mandatory.
Set merge and push-protection rules once and apply them across every targeted repository at once — targeted by visibility, an explicit repo list, or a name pattern — instead of configuring each repository by hand. Rulesets compose with a repository's own settings on a strictest-wins basis. An admin can bypass a blocked merge only when their role is explicitly allowed to for every ruleset in play, and every bypass is written to your audit log.
A repository governed by an org ruleset shows which rulesets are contributing to its floor directly in its own Branch protection section — you can still configure that repository to be stricter than the floor, but never looser.