Rulesets govern what happens inside a repository. Nothing in a ruleset stops somebody deleting it.
Repository lifecycle — creation, deletion, transfer, visibility change, naming — is a separate governance surface with its own mechanism, and it is the one most enterprises have never configured because they assumed rulesets covered it.
The short answer
Section titled “The short answer”A repository policy is a collection of restrictions on repository lifecycle events, with targeting for which repositories it applies to and an allow list for who may bypass it.
It controls five things:
- Which visibilities are permitted for new repositories and for visibility changes
- Who can create repositories
- Who can delete repositories
- Who can transfer repositories out of an organisation
- How people can name repositories
Targeting works like rulesets. Organisations are selected first — all, a specific list, or fnmatch patterns — and then repositories within them, either all or by custom repository properties.
The allow list designates “which roles can bypass the restrictions in this policy.”
There is a limit. GitHub documents up to 75 total policies and rulesets per organisation, and 75 per enterprise. Rulesets and policies share that budget.
Why this is a separate mechanism
Section titled “Why this is a separate mechanism”The distinction is worth being precise about, because it determines where you look for a control.
Rulesets govern changes to refs. Branches, tags, pushes. Every rule in the ruleset catalogue is about what may be written to a repository.
Repository policies govern the repository itself. Its existence, its name, its visibility, its location.
These are different classes of event and neither mechanism covers the other. A ruleset requiring pull requests does not prevent the repository being deleted. A policy restricting deletion does not require review of a change.
Enterprise policies overlap partially. The enterprise settings covering repository creation, deletion and transfer, and visibility changes exist too — and they apply enterprise-wide with no targeting. Repository policies are the targeted version of the same concerns.
GitHub names the advantages of policies over the older mechanisms: “more flexible targeting of organizations and repositories”, the ability to “give certain actors the option to bypass the policies”, and greater transparency since “they’re visible to organization owners”.
The five controls
Section titled “The five controls”Visibility. Which visibilities may be selected for a new repository, and which visibility changes are permitted. This is the control that prevents an internal repository becoming public, which is the single highest-consequence one-click action available in an enterprise.
Creation. Who may create repositories. The blunt version is an enterprise policy restricting creation to organisation owners; the targeted version allows self-service in some organisations and not others.
Deletion. Who may delete. Deleting a repository is recoverable for a limited window and then it is not, and the people who most want to delete a repository are usually the people who should not be making that call unilaterally.
Transfer out of an organisation. The control people forget. A transfer removes the repository from your governance entirely — different organisation, possibly a personal account, outside every enterprise ruleset and every audit expectation. It is arguably the most consequential of the five.
Naming. How repositories may be named. Enforcing a convention at creation is the only point at which it is cheap; renaming later breaks every reference.
Allow lists and delegated bypass
Section titled “Allow lists and delegated bypass”The allow list is a bypass list, expressed as which roles may bypass the restrictions.
Delegated bypass is different and more interesting. GitHub documents it as available for repository deletions and visibility changes: an administrator requests an exception, and designated reviewers approve or deny it.
This is the mechanism that makes a strict policy workable. Without it, a policy restricting deletion either blocks legitimate deletions or has a bypass list large enough to be meaningless. With it, the action is permitted but reviewed.
Which converts a hard control into a reviewed one, and reviewed controls are what most compliance frameworks are actually asking for. A deletion that happened with an approval attached is a much better answer than either “it was blocked” or “anyone could do it”.
Designate real reviewers. A delegated bypass whose reviewer group is a single overloaded person becomes a queue, and a queue becomes a workaround.
Where each lifecycle control belongs
Section titled “Where each lifecycle control belongs”There are now three overlapping surfaces covering some of the same ground, and knowing which to use avoids configuring a control twice or not at all.
| Concern | Enterprise policy | Repository policy | Ruleset |
|---|---|---|---|
| Who may create repositories | Yes, enterprise-wide | Yes, targeted | No |
| Which visibilities may be created | Yes, enterprise-wide | Yes, targeted | No |
| Who may change visibility | Yes, enterprise-wide | Yes, targeted, with delegated bypass | No |
| Who may delete or transfer | Yes, enterprise-wide | Yes, targeted, with delegated bypass | No |
| Repository naming | No | Yes | Branch and tag names only |
| Forking | Yes | No | No |
| Anything about branches or pushes | No | No | Yes |
The rule of thumb: if the requirement is uniform across the whole enterprise, an enterprise policy is simpler and has no preview dependency. If it varies by repository category, a repository policy with property targeting is the mechanism.
Do not configure both for the same concern without deciding which is authoritative. Overlapping controls that disagree produce behaviour nobody can explain, and the person debugging it a year from now will not know which was intended.
Record the choice in the policy inventory. For each lifecycle concern: which mechanism, what value, why that mechanism rather than the other.
What the controls are actually protecting against
Section titled “What the controls are actually protecting against”Worth being concrete, because lifecycle governance is frequently configured as ceremony rather than as risk reduction.
Accidental public disclosure. Someone changes visibility to public intending to share with a colleague. The repository is indexed within minutes, and clones and forks made in that window persist regardless of what you do next. This is the scenario the visibility control exists for, and it is not hypothetical — it is one of the most common ways source code leaves an organisation.
Loss of a repository somebody depended on. A team deletes a repository they believe is unused. Something in the estate consumed it — a workflow, a dependency, a documentation link. Deletion is recoverable within a window and then it is not.
Escape from governance. A transfer moves the repository outside every enterprise ruleset, every audit expectation, and possibly outside the enterprise entirely. Nothing in the code changed; everything about who can see and control it did.
Loss of the audit trail. A repository that no longer exists takes its issue history, its pull request reviews and its approvals with it. If those were the evidence for a control, the evidence is gone. The audit log records the deletion but not what was deleted.
Metadata that was never set. A repository created outside the governed path has no owner, no tier, no classification — so no targeted policy applies to it, forever, until somebody notices. This is the quiet failure, and it is the argument for governing creation rather than only restricting it.
Each of these is a real incident somebody has had. A lifecycle policy set that does not map to at least one of them is probably solving a problem you do not have.
Designing a lifecycle policy set
Section titled “Designing a lifecycle policy set”A small set covering the events that matter.
Visibility policy, applied everywhere. Public repository creation restricted, and visibility changes to public requiring bypass or delegated approval. This is the highest-value single policy in the set and it is uncontroversial in most enterprises.
Deletion policy, targeted at production-tier repositories. Deleting a development scratch repository needs no ceremony. Deleting something that serves production does.
Transfer-out policy, applied everywhere. There is essentially no legitimate routine reason for a repository to leave the enterprise, and the ones that exist are rare enough to justify an exception process.
Naming policy where a convention exists and is consumed. If tooling parses repository names, enforce the format. If not, do not — a convention with no consumer is friction.
Creation policy only if self-service is a problem. Restricting creation creates a queue. Prefer collecting metadata at creation over preventing creation; see repository lifecycle governance.
The 75-policy budget
Section titled “The 75-policy budget”An easily-missed constraint with real design consequences.
Policies and rulesets share a limit of 75 per organisation and 75 per enterprise.
Which means fine-grained per-team policies do not scale. An enterprise with forty teams cannot have a policy per team, and an approach that starts that way hits the ceiling before it is finished.
The design that fits: a small number of policies, each targeted by custom property, covering categories rather than teams. Ten policies covering four repository tiers is sustainable; ninety covering individual cases is not.
It is also an argument for metadata discipline. Property-based targeting is what allows one policy to cover a category that grows, and the alternative — a policy per exception — consumes the budget quickly.
Naming policies specifically
Section titled “Naming policies specifically”Naming deserves its own treatment because it is the control most often enforced for the wrong reason and most valuable when enforced for the right one.
The wrong reason is tidiness. A convention imposed because inconsistent names look untidy generates friction on every repository creation and delivers nothing measurable.
The right reason is a consumer. Something downstream parses the name: a deployment pipeline that derives an environment from a prefix, a catalogue that groups by team, an access-provisioning script that matches a pattern. When a consumer exists, a malformed name is a real failure and enforcement prevents it.
Which means the question to ask is: what breaks if a repository is named badly? If the honest answer is nothing, do not enforce.
Renaming is expensive, which is why enforcement at creation is the only cheap moment. A rename breaks clone URLs (redirected, but scripts that parse output can still break), CI configuration referencing the path, documentation links, deploy keys and app installations scoped by name, and anything that stored the name rather than the ID.
Prefer a prefix or suffix convention to a rigid full-name pattern. svc-, lib-, infra- is learnable and permissive. A pattern requiring team, tier and component in a fixed order is a convention people will fight and get wrong.
And prefer metadata to naming for anything that might change. A repository’s tier belongs in a custom property, where it can change. Encoding it in the name means a rename every time it does — which is why nobody ever does, and the names become wrong.
Rolling out lifecycle policies
Section titled “Rolling out lifecycle policies”Different from rulesets in one important way: policies are documented as being either Disabled at creation or Active. There is no evaluate mode equivalent to rulesets’ observation mode, so the “watch before enforcing” technique is not available in the same form.
-
Measure first, from the audit log. How often are repositories deleted, transferred, or made public today? The audit log has the answer, and it is usually a smaller number than people expect.
-
Identify who does it. If deletions are all performed by three platform engineers, the allow list is obvious. If they are spread across forty people, the policy will surprise a lot of them.
-
Announce before enabling. Especially for creation and naming policies, which people hit immediately.
-
Start with transfer-out and public-visibility. Rare, high-consequence, and almost nobody is inconvenienced.
-
Configure delegated bypass before enabling deletion restrictions, so there is a working path on day one.
-
Enable one policy at a time, and watch the audit log for the events it should now be preventing.
-
Review exceptions monthly. The exception pattern tells you whether the policy matches reality.
Detection when prevention is not available
Section titled “Detection when prevention is not available”Because repository policies are in preview and because some enterprises will not adopt a preview feature for a control, detection is the fallback — and it is worth having regardless.
Every lifecycle event appears in the audit log. Repository created, deleted, transferred, visibility changed, renamed. These are exactly the events worth alerting on rather than reviewing quarterly.
An alert on visibility change to public is the highest-value single alert in an enterprise. The window in which a disclosure can be contained is minutes, and a quarterly review is not a control.
Transfer-out and deletion alerts are lower volume and worth having for the same reason.
Repository creation without required metadata is a detection worth building: a scheduled job listing repositories with unset custom properties turns the silent-gap problem into a work item.
Stream the log rather than polling it. GitHub documents 180-day retention for the audit log, with Git events retained for seven days — and streaming to a destination you control removes the retention question entirely. See audit log streaming.
Detection is not equivalent to prevention, and it should not be recorded as though it were. What it gives you is a bounded response time, which for irreversible events is the difference between an incident and a catastrophe.
Run both where you can. A preventive policy stops the routine case; the alert catches the bypass, the exception and the thing the policy did not target.
The organisation owner’s view
Section titled “The organisation owner’s view”One documented advantage of repository policies is worth drawing out: GitHub notes that policies are “visible to organization owners”, which older enterprise settings are not in the same way.
Visibility changes the politics of governance. A control an organisation owner can see, understand and explain to their teams is one they will support. A control that manifests only as an unexplained rejection is one they will escalate about.
It also removes a support burden. When a developer asks their organisation owner why they cannot create a public repository, the owner can look and answer, rather than filing a ticket with the enterprise team.
Which argues for using the visible mechanism where you have a choice, even when the older enterprise setting would technically work. The governance that survives is the governance people can see the reason for.
And it argues for naming policies descriptively. A policy named for what it prevents and why is self-documenting to the organisation owner reading it; one named after the project that introduced it is not.
Common mistakes
Section titled “Common mistakes”Assuming rulesets cover lifecycle events. They do not; the control is absent.
Forgetting transfer-out. It removes a repository from your governance entirely.
Restricting deletion with no bypass path. Legitimate deletions queue up and somebody eventually gets a broad exception.
Enabling policies without measuring current behaviour. You cannot predict the disruption.
A policy per team. The 75 shared budget will not accommodate it.
Enforcing naming with no downstream consumer. Friction with no benefit.
Treating preview features as durable controls. Note the dependency; re-verify.
Restricting creation instead of governing it. A queue gets bypassed; a self-service path with metadata collection does not.
Reviewing the policy set
Section titled “Reviewing the policy set”Lifecycle policies are set-and-forget in a way rulesets are not, which is precisely why they need a review cadence.
Annually, walk each policy and ask three questions: is the mechanism still the right one, is the targeting still correct, and has the preview status changed?
Check the allow lists. They are the part that decays. People change roles, leave, or acquire the bypass for a one-off migration that ended two years ago.
Check for unset properties. Every repository that no policy targets is a gap, and the number should be zero or explained.
Check the exception record. If delegated bypass is in use, the pattern of requests is the most honest feedback available on whether the policy matches how people work.
Re-verify preview status. A feature that was preview when you adopted it may now be generally available — which is good news and worth recording — or its behaviour may have changed in a way that affects your control.
Compare against the audit log. The events the policy should be preventing should have stopped appearing except through the bypass path. If they have not, the policy is not doing what you think it is, and that is worth finding out during a review rather than during an audit.
Mental model
Section titled “Mental model”Rulesets govern what enters a repository; repository policies govern the repository’s existence. The lifecycle events — created, renamed, made visible, moved, deleted — are the ones that are hardest to undo and least covered by default, and they are governed by targeting plus a reviewed exception path rather than by prohibition.
What you learned
Section titled “What you learned”- Repository policies are documented as being in public preview and subject to change
- They control visibility, creation, deletion, transfer out of an organisation, and naming
- Targeting selects organisations by list or
fnmatchpattern, then repositories by all or by custom properties - The allow list defines which roles may bypass the restrictions
- Delegated bypass, itself in public preview, provides an approval flow for deletions and visibility changes
- Policies and rulesets share a limit of 75 per organisation and 75 per enterprise
- Rulesets govern ref changes and cannot express lifecycle controls
- Transfer-out is the most consequential and least-configured control
- There is no evaluate mode, so measure from the audit log before enabling
Exercise
Section titled “Exercise”Use an enterprise you administer.
-
Search the audit log for repository deletions in the last ninety days. Predict: how many, and by whom?
-
Do the same for transfers out of an organisation and for visibility changes to public.
-
Count your existing rulesets and policies against the 75-per-enterprise budget. How much headroom is there?
-
Design a visibility policy: what is permitted at creation, what changes require approval, who is on the allow list.
-
Identify who would be the designated reviewers for a delegated bypass on deletion. Predict: would they respond within a day?
-
Check whether any repository could currently be transferred out of the enterprise by someone who should not be able to.
-
Write the announcement for the first policy you would enable.