Why GitHub Is Rebuilding Code Storage

GitHub, the Microsoft-owned code-hosting platform, says it has added computing capacity and is rebuilding its storage to handle a surge in saved code changes. Its engineers want to keep growing automated workloads from slowing the updates developers and their software tools depend on.

At its October 28 Universe conference, Microsoft CoreAI executive Jay Parikh reported that GitHub had added 4 million CPU cores, 160 petabytes of high-speed storage and 50 terabits per second of network capacity during 2026.

Developers and agents made 7.38 billion commits on GitHub in September, more than five times as many as a year earlier, according to the company’s October 6 engineering account. GitHub has not specified what share came from agents.

Why More Copies Can Slow Updates

Git, the version-control software underlying GitHub, records changes to a project’s files. A repository holds those files and their revision history. Developers send saved changes to GitHub in a push, which can carry many commits.

AI coding tools can do more than suggest snippets. By April 2025, GitHub’s Copilot coding assistant had gained an Agent Mode that could run commands, fix issues and work across multiple files. GitHub principal software engineer Brian Celenza describes agents that save a checkpoint after nearly every action and wait for each push before continuing. Many agents can also work on separate branches, or parallel versions, of the same repository.

Automated builds, tests and security scans fetch the saved code, multiplying demand for reads. A push has to be stored safely and made consistently visible before the next agent or automated job builds on it.

GitHub’s existing storage system keeps several complete copies of each repository, typically five. Those copies protect the data and spread requests to read it across servers. They also coordinate updates so the website, software tools and automated tests see a consistent accepted state.

At busy repositories, every copy participates in writes, so adding another copy to serve more readers also increases the coordination behind each update. A slow healthy copy can hold up a push. More read capacity can therefore make writes slower.

GitHub is separating the two jobs. Its new design places the authoritative repository data in Azure Blob Storage, Microsoft’s durable cloud storage service. Separate computers cache that data and answer read requests. Adding these read-serving workers is intended to absorb bursts of automated checks without adding another full participant to every write.

Letting Separate Branches Move Together

Developers and agents pushing changes to their own branches in one busy repository can still end up in the same queue. GitHub’s engineers describe this bottleneck during the Azure migration. The older design holds a lock across the whole repository while an update is accepted. With copies spread between GitHub’s data centers and Azure, each write requires several network round trips, each taking about 25 milliseconds. Other branch updates wait behind it.

GitHub is narrowing that ordering to individual references, the pointers that identify a branch’s saved state. Updates to different branches can then proceed at the same time. Updates to a shared reference still have to stay ordered, so a client reading after an accepted update sees that state or a newer one.

Write throughput measures how many updates the system can handle per unit of time. GitHub reports three to four times higher throughput and lower latency, or shorter waits, for writes to different references in internal tests using realistic traffic. Each write still encounters the cross-region delay; independent writes can overlap instead of forming one repository-wide queue. A separate internal benchmark of the broader storage redesign reached up to 35 times higher write throughput, GitHub says.

Read caches that refresh only in the background can lag behind newly stored changes. GitHub says handling every kind of read will require fetching updated branch state and changed data when the request arrives. The repository copies accepting writes must still agree on each update, so that coordination continues to limit write throughput.

What the Agent Comparison Measures

GitHub’s 2026 Octoverse analysis reports 34.3 billion commits across public and private repositories for October 1, 2025, through September 30, 2026. GitHub has not specified whether September’s engineering tally uses the same counting rules.

Within the new report, repositories created during the year with an agent configuration file averaged eight times as many commits as new repositories without one. Such a file tells an AI coding agent how to work in a project. Its absence does not rule out AI use.

The comparison is between observed groups, with no published group sizes or controls for differences in their work. It measures saved snapshots per repository, not the value of completed tasks. Parikh’s stated goal is completed features and fixes: “Completed work, not more code, is the output that matters.”

Scaling After Service Failures

The expansion follows repeated service failures that disrupted development work. On August 17, an outage lasted seven hours and 47 minutes, affecting authentication, code collaboration, GitHub Actions automation and Copilot, among other services.

GitHub CTO Vladimir Fedorov’s account of that outage says a critical component failed to scale when traffic reached a new peak. Capacity pressure spread into authentication and other services. During recovery, errors in some Copilot services triggered a client retry loop that added traffic; teams had to curb that behavior before safely restoring traffic.

Fedorov also acknowledged that GitHub’s operating practices had fallen behind the pace and complexity of change. Alongside more hardware, the company was improving testing, rollouts and alerting, isolating critical systems and limiting retries between services.

GitHub’s October 28 update puts completion of its move to multiple Microsoft Azure cloud regions in early 2027.