How GitHub runs at scale: spoke clusters, shared fork storage and keyless OIDC

A technical deep dive on dev.to, originally published on the author's blog tamiz.pro, unpacks the three mechanisms that let GitHub operate as a global code platform: regional 'spoke' clusters, git's alternates mechanism for storing forks cheaply, and keyless OIDC authentication for CI pipelines. The author, Tamizuddin, works from GitHub's public documentation and frames the piece around concepts and trade-offs rather than internals GitHub has not disclosed.

Spokes put a full serving surface in every region

According to the post, GitHub partitions its platform into regional units in a hub-and-spoke topology. Each spoke is a near-complete deployment of the user-facing surface: an API gateway answering REST and GraphQL calls, the services that terminate git push and fetch locally, and the plumbing that receives and emits webhook events. Because most developer interactions are read-heavy and stay within a region, routing them locally keeps perceived latency low.

The hard problem is global consistency. The post describes an eventually consistent model in which a developer in Tokyo and one in São Paulo may briefly see different state while talking to separate spokes. Conflict handling is eased by git's content-addressed, largely append-only object model, where new commits and refs do not overwrite existing state, but mutable data such as repository settings, branches, tags and pull request status requires explicit conflict detection. Under strain, high-traffic operations are throttled or queued so one region cannot overwhelm the others, and consistency guarantees are chosen per operation: a branch push may be globally strong while a profile update is allowed to converge asynchronously. Operationally, spokes deploy independently behind canary releases, cross-region metrics are correlated to trace latency to its origin, and a degraded spoke hands its traffic to another region while user sessions and webhook events survive the move.

Forks share objects through git alternates

The second mechanism sits at the storage layer. Git lets a repository point at another directory of objects via the .git/objects/info/alternates file; object lookups check the local store first and fall back to the alternate location. When GitHub creates a fork, per the post, the shared bulk of commit and tree history can stay in the parent's object store while the fork writes only the objects unique to it. For a popular repository with millions of forks, the piece argues, this is the difference between one shared base plus small local deltas and duplicating an entire history for every fork. Network behaviour benefits too, since packfiles shrink when a client already holds the parent repository's objects.

The trade-offs are coordination problems. Garbage collection has to be coordinated across repositories that share objects, so a fork never loses history it depends on. Heavy fork creation or pack generation must be isolated with queues and resource quotas so it does not starve other tenants. And entitlements must be enforced so a fork user can read the shared objects they are allowed to see without leaking data from the parent or from sibling forks.

Keyless OIDC retires static CI secrets

The third pillar concerns CI/CD. GitHub Actions workflows routinely call cloud providers, secrets managers and SaaS APIs, and the traditional approach stores long-lived static credentials in secrets. The post describes the keyless alternative built on OpenID Connect: GitHub issues a short-lived signed JWT asserting the workflow's identity and permissions, the external service verifies it against public keys, and the token's scopes and expiry bound what it can do and for how long. With no credential at rest, nothing can leak into logs, images or repositories and keep working for years — an approach the author ties to zero-trust principles.

Why it matters

The piece works as a field guide to the patterns behind a hyperscale multi-tenant system: choose consistency guarantees per operation rather than system-wide, deduplicate storage by reference instead of by copy, and replace durable credentials with short-lived verifiable identity. Each pattern generalises well beyond code hosting, to any globally distributed SaaS, any multi-tenant storage layer and any pipeline that still ships static secrets. It also explains two things users take for granted: why forking a repository with a long history feels instant and cheap, and why CI security guidance keeps converging on OIDC over stored keys.