Would the project accept contributions to manage enterprise-level settings?

# Would the project accept contributions to manage enterprise-level settings?

## Prerequisites

**Is the functionality available in the GitHub UI?**

Yes. Enterprise accounts expose a policy surface that `safe-settings` cannot currently reach: enterprise rulesets, enterprise custom properties, enterprise Actions policies, and enterprise code security configurations, all under **Enterprise settings → Policies / Rulesets / Custom properties / Code security**.

- [About enterprise policies](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/about-enterprise-policies)
- [Managing code rulesets for repositories in your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/managing-policies-for-code-governance)
- [Managing custom properties for repositories in your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/managing-custom-properties-for-repositories-in-your-enterprise)

**Is the functionality available through the GitHub API?**

Yes, and this is the part that changed since the topic was last discussed. All of the following are documented REST endpoints today:

| Surface | Endpoints | Status |
| --- | --- | --- |
| [Enterprise rulesets](https://docs.github.com/en/enterprise-cloud@latest/rest/enterprise-admin/rules) | `GET/POST /enterprises/{enterprise}/rulesets`, `GET/PUT/DELETE /enterprises/{enterprise}/rulesets/{ruleset_id}` | GA ([Mar 2025](https://github.blog/changelog/2025-03-24-enterprise-custom-properties-enterprise-rulesets-and-pull-request-merge-method-rule-are-all-now-generally-available/)) |
| [Enterprise custom properties](https://docs.github.com/en/enterprise-cloud@latest/rest/enterprise-admin/custom-properties) | `GET/PATCH /enterprises/{enterprise}/properties/schema`, `GET/PUT/DELETE /enterprises/{enterprise}/properties/schema/{name}` | GA ([Mar 2025](https://github.blog/changelog/2025-03-24-enterprise-custom-properties-enterprise-rulesets-and-pull-request-merge-method-rule-are-all-now-generally-available/)) |
| [Enterprise Actions policies](https://docs.github.com/en/enterprise-cloud@latest/rest/actions/permissions) | `GET/PUT /enterprises/{enterprise}/actions/permissions` (+ `/organizations`, `/selected-actions`, `/workflow`, `/self-hosted-runners`, `/fork-pr-*`, `/artifact-and-log-retention`) | GA |
| [Enterprise code security configurations](https://docs.github.com/en/enterprise-cloud@latest/rest/code-security/configurations) | `GET/POST /enterprises/{enterprise}/code-security/configurations`, `PATCH/DELETE .../{configuration_id}`, `.../defaults`, `.../attach` | GA |

**Is it reachable by a GitHub App?** This is the historical blocker, and it has been lifted:

- [Enterprise-level access for GitHub Apps and installation automation APIs](https://github.blog/changelog/2025-07-01-enterprise-level-access-for-github-apps-and-installation-automation-apis/) (Jul 2025, public preview) — Apps can be **installed on an enterprise account** and were given enterprise permissions, including *Enterprise organization installations* ("view, create, edit, and remove installations in each organization"), *custom properties*, *SSO & SCIM*, *people management*, and *organization creation*. Each enterprise installation gets its own rate-limit budget (15,000 req/hr).
- [Enterprises can now install third-party GitHub Apps](https://github.blog/changelog/2026-08-07-enterprises-can-now-install-third-party-github-apps/) (Aug 2026) — public Apps created outside the enterprise can now be installed on an enterprise account.

## The ask

In [discussion #335](https://github.com/github-community-projects/safe-settings/discussions/335) the stated limitation was:

> The permissions available to a GitHub app allow it to only manage settings for repositories and its resources. […] it doesn't manage settings for Enterprise or org.

That constraint was accurate when it was written, but it is no longer true for the enterprise level. So the question is one of project direction rather than feasibility:

**Is the project open to contributions that add an enterprise layer to the settings hierarchy — and if so, what shape would you want it to take?**

We would rather ask before writing code than show up with a large PR that cuts against the direction you have in mind.

## How this differs from existing issues

- [#827 — Support configuring multiple organizations centrally](https://github.com/github-community-projects/safe-settings/issues/827) is about **config topology**: one instance and one admin repo governing many orgs. It is about where org config lives and which installation token applies it.
- [#782 — don't take fixed: installations[0]](https://github.com/github-community-projects/safe-settings/issues/782), plus [#1044](https://github.com/github-community-projects/safe-settings/pull/1044) and [#1053](https://github.com/github-community-projects/safe-settings/pull/1053), are about **multi-installation correctness** during full sync.
- [#409](https://github.com/github-community-projects/safe-settings/issues/409) and [#200](https://github.com/github-community-projects/safe-settings/issues/200) are GHES suborgs and EMU IdP team linking.

This request is different in kind: not "manage more orgs", but **manage resources that are owned by the enterprise account itself** and have no org-level equivalent — an enterprise ruleset applies across every org in the enterprise and cannot be expressed as N org rulesets, and enterprise custom properties are precisely the mechanism that removes the need to sync property schemas org by org.

The overlap with #827 is real but narrow, and it is mostly about auth plumbing. Happy to fold this into #827 if you would rather track it there.

## Sketch of a possible shape

Deliberately vague on internals, because the design should follow your preferences:

1. **A new top level in the hierarchy.** Today precedence runs org → suborg → repo. This would add `enterprise` above org, configured in the admin repo (e.g. `.github/settings.yml` gaining an `enterprise:` block, or a dedicated `enterprise/` path under `CONFIG_PATH`), applying only to genuinely enterprise-scoped resources.
2. **New plugins, same contract.** `enterprise_rulesets`, `enterprise_custom_properties`, `enterprise_actions_policies`, `enterprise_code_security` — each following the existing plugin lifecycle so that dry-run/nop diffs, PR check comments, and the error reporting path keep working unchanged.
3. **Strictly opt-in.** Absent enterprise config and absent an enterprise installation, behavior is byte-for-byte what it is today. No existing deployment changes.
4. **Two auth contexts, made explicit.** An enterprise installation grants access to the enterprise account only — it explicitly does *not* act as an installation inside each org or repo. So enterprise plugins would authenticate with the enterprise installation token while org/suborg/repo plugins keep using org installation tokens. This is the main design question we would want your read on.

### Open questions for maintainers

1. **Appetite.** Is an enterprise layer in scope for `safe-settings` at all, or do you consider enterprise governance out of the project's intended boundary?
2. **Auth model.** Would you prefer the enterprise installation token approach above, an enterprise-owned App as you suggested in [#827](https://github.com/github-community-projects/safe-settings/issues/827#issuecomment-2905455977), or a separate deployment mode driven by env vars?
3. **Preview surface.** Some enterprise App permissions are still public preview. Is depending on a preview permission acceptable, or would you want this gated behind an env flag until GA?
4. **Sequencing.** If there is appetite, would you want one narrow vertical slice first (enterprise custom properties alone, as the smallest useful unit) to settle the auth and hierarchy questions before adding the rest?
5. **Process.** Given the move to `github-community-projects` and the trusted-contributor model mentioned in [#812](https://github.com/github-community-projects/safe-settings/discussions/812), should a change of this size start as a discussion, an RFC-style issue, or a draft PR?

## Willingness to do the work

We run a self-hosted `safe-settings` across two orgs in one enterprise and are already contributing upstream fixes we needed along the way — [#1044](https://github.com/github-community-projects/safe-settings/pull/1044), [#1052](https://github.com/github-community-projects/safe-settings/pull/1052), [#1053](https://github.com/github-community-projects/safe-settings/pull/1053), [#1065](https://github.com/github-community-projects/safe-settings/pull/1065). We are willing to implement and maintain this, in whatever sequence and shape you prefer. A "not in scope" answer is also useful — it tells us to solve the enterprise layer outside `safe-settings` rather than wait.

Start with discussion #335 and the existing org → suborg → repo hierarchy, then review the proposed .github/settings.yml or CONFIG_PATH enterprise entry and plugin lifecycle. The first milestone is maintainer agreement on scope, authentication, preview gating, and sequencing; a narrow enterprise custom-properties slice could define what done means before broader implementation.

Written by the indexing model from the issue text.