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

[rafaelleonardocruz]

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
• Managing code rulesets for 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	GET/POST /enterprises/{enterprise}/rulesets, GET/PUT/DELETE /enterprises/{enterprise}/rulesets/{ruleset_id}	GA (Mar 2025)
Enterprise custom properties	GET/PATCH /enterprises/{enterprise}/properties/schema, GET/PUT/DELETE /enterprises/{enterprise}/properties/schema/{name}	GA (Mar 2025)
Enterprise Actions policies	GET/PUT /enterprises/{enterprise}/actions/permissions (+ /organizations, /selected-actions, /workflow, /self-hosted-runners, /fork-pr-*, /artifact-and-log-retention)	GA
Enterprise 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 (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 (Aug 2026) — public Apps created outside the enterprise can now be installed on an enterprise account.

The ask

In discussion #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 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], plus #1044 and #1053, are about multi-installation correctness during full sync.
• #409 and #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, 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, 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, #1052, #1053, #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.