[bgrainger]

We've been running GitHub Enterprise Server (first on-prem, now in a Cloud VM) for many years. Size: low thousands of repos, less than a terabyte of total data.

Pros: Not affected by GitHub.com downtime; stability has generally been good for us; you have full control over the org and user names on the instance (instead of having to pick globally-unique ones on github.com); can sync licenses between GHES and github.com if you want to use some private repos on github.com; can raise your API rate limit as high as you want; probably cheaper to provide your own storage.

Cons: New features from github.com can take months (or longer) to be released to GHES; many third-party integrations only work with github.com not GHES; if something goes down, it's now your fault; Actions requires bring-your-own self-hosted runners; autoscaling your self-hosted runners is non-trivial.

The last point is probably the biggest negative for us. We're trying to use GitHub Actions more, but I don't really want to have to manage a pool of autoscaling runners. (I'm doing it, though.) If GitHub provided an add-on service to connect GitHub-managed cloud runners to GHES, I'd use it. (Needing to always keep code private and on-premises is not a requirement for us.)

[pchernik]

Have you considered the "Enterprise Managed Users" feature? In my understanding this is where GitHub runs a separate instance of GitHub for you (i.e. it's not on public github.com) and one of the benefits (in my understanding) is things like globally-unique org names and such no longer applies.

[bgrainger]

That's a good point: Enterprise Managed Users does solve the globally-unique-username issue, but comes with its own list of limitations: https://docs.github.com/en/enterprise-cloud@latest/admin/ide...

We concluded it was overkill for us (but we're not primarily using github.com anyway).