These past few weeks at Entire have been so exciting. We just launched our git hosting platform, and the reaction from the community has been incredible. People are genuinely embracing our product and our vision.
But I’ve also seen some completely fair curiosity. Some people are wondering: why are we trying to build a git hosting platform? GitHub works has done the job for almost two decades. It also has established alternatives like GitLab and Bitbucket, and there is a new wave of git hosting competitors popping up like Tangled, Cursor Origin, and gitlawb. Why try to compete with them?
My answer is ripe with bias, but I truly believe Entire is the git hosting platform that will matter in the end.
To understand why there is a sudden race to rebuild git hosting, and why Entire’s approach is the one that will actually last, we have to look at how git hosting works under the hood.
The Beauty of GitHub
First, let's give GitHub credit where it’s due. I love GitHub. It is the platform where I first dived into coding, made my first open source contribution, and landed my first Developer Advocacy job. My Developer Relations career started at GitHub five years ago, and it changed my life forever. I found the career path I truly fit into.
Beyond that, GitHub made software development easier for the entire industry. Before it existed, people struggled to collaborate on code. Some developers used email, while others used systems that constantly overwrote lines of code and caused unresolvable merge conflicts.
GitHub put a beautiful interface layer on top of git (a command-line tool that is not always the easiest to navigate) and made collaboration feel natural. The solution was so good that people often use "git" and "GitHub" interchangeably, even though they are different things. The pull request was a brilliant invention that allowed us to learn from each other, review code, and build together.
But platforms like GitHub were designed for human traffic.
The Problem
I don’t know if you noticed, but lately GitHub has been having outages and performance issues. It’s becoming an expected part of the developer experience. Even GitHub acknowledged that AI was the reason for the majority of its reliability issues. Before I joined this company, I ignorantly believed that developers at GitHub were leaning too heavily into vibe coding creating bugs that caused the platform to crash, but the true issue is agent traffic.
GitHub has a system that works well for the human pace of development, where humans search for code, clone repos, create branches, push commits, and open pull requests fairly slowly.
For example, it might take me days after cloning a repo, getting familiar with it, and trying to solve a problem before I am ready to open a pull request.
GitHub’s Infrastructure is Centralized
On standard GitHub.com, GitHub stores data in the United States by default. I will note that for enterprise customers with specific data residency requirements, GitHub also offers regional hosting through separate GHE.com environments in other parts of the world. But the majority of GitHub’s 180 million+ users are using the free or Pro options. So, we can conclude that most of the traffic is going to the central servers in the US.
GitHub’s hosting infrastructure includes repo storage, networking, APIs, authentication services, databases, search, and Git servers that respond to commands like git clone, git fetch, and git push. Inside GitHub’s infrastructure is a system called Spokes. Spokes stores multiple replicas, or working copies, of a repository on different file servers. This helps make sure the repo remains available if one server or copy becomes inaccessible.
GitHub also has Points of Presence, or PoPs, around the world. A PoP is mainly an entrance into GitHub’s network. It helps route the request, but the full repository operation is completed by GitHub’s hosting systems, not by the PoP itself.
This works pretty fine for the pace of human development.
But it doesn't work well for the pace of agent development.
Agent Traffic on Traditional Git Hosting Platforms
Picture this: I am in France and I have an agent. I could have it search for a repo, clone it, fetch its contents, read hundreds of files, make changes, push commits, and open a pull request within five minutes. I could even have multiple agents doing this at the same time, either across many repos or while solving several issues in one repo.
My agent in France sends its request to the closest GitHub PoP. The PoP routes the traffic to GitHub’s central network. When it gets there, GitHub’s network is chugging along processing API requests, searches, git commands on many servers in parallel.
The PoP says: “Hey, Rizel’s agent wants to put up this PR.”
GitHub says: “You’re going to have to wait. I am processing as best as I can requests from thousands of agents across the globe. You will have to wait in line. Here’s a rate limit.
And if things get really bad, GitHub might say: “This is way too much. I’m shutting down for a little. I’m timing out. I’m overwhelmed.”
Entire’s Approach: Distributed Git Hosting
Our C-suite (who, by the way, were previously C-suite at GitHub, meaning they know these scaling issues inside and out) looked at this bottleneck and asked a simple question: what if we stored and served repositories from full Git hosting systems running in different regions around the world?
Instead of using a European location only to route traffic back to the US, Entire can run the storage and Git services needed to serve a repository directly from Europe. That way, if Rizel is in France, Rizel can choose Europe as her region and let her agents perform more of their work there.
Starting With Mirrored Repositories
To help people transition, we are starting with mirrored repos. We know that moving all your repos, teams, permissions, and workflows to a new platform is inconvenient. I currently have approximately 287 repos myself (Don’t judge me. I make a lot of demo apps. It’s my job).
We’re encouraging users to mirror the repos they already have on GitHub to Entire. Mirroring means Entire creates a synchronized copy of your GitHub repo in a region you choose. That copy includes the code, branches, commits, and Git history needed to serve many Git requests.
If my repo is mirrored into Entire’s European region, my agent in France can clone, fetch, search, and read from that European copy instead of making GitHub process every read. This reduces the amount of repetitive agent traffic hitting GitHub. This reduces the amount of repetitive agent traffic hitting GitHub.
This transition does have a limitation. GitHub is still the official home of that repository. If my agent pushes to a GitHub-backed branch, that write operation still has to go back to GitHub. GitHub still has to accept the push, update the repo, and store the change through systems like Spokes.
But, we do offer region-local branches for mirrored repositories. These branches can stay within Entire instead of being pushed back to GitHub.
So with mirrors, reads can happen through Entire, writes to GitHub backed branches still depend on GitHub, but users can create branches that remain within an Entire region and don’t depend on GitHub.
The Next Step: Native Entire Repositories
Soon, we will roll out native repositories created on Entire with zero dependency on GitHub.
Those repositories will live on Entire’s regional network, allowing agents to read from infrastructure closer to where they are running while writes are handled by the repository’s chosen region. That means agent traffic no longer has to pass through GitHub’s infrastructure. Entire can spread that traffic across its own regions and design the workflow around the speed and volume of coding agents.
The Biggest Step: Decentralization (Not the one you’re thinking of)
Decentralization is a heavy word that carries a lot of baggage from blockchain, crypto, and web3, but decentralization just means: Entire would not have to operate every server that stores and serves repositories.
And Git was designed to be decentralized. Out of convenience, our industry didn’t follow through on that promise, but we have an idea for it.
We envision giving users the option to self host their own nodes. In this case, a node is a server, or group of servers, running the storage and Git services needed to host repos and respond to reads and writes. For example, I could run a node inside my company’s own European cloud account or data center.
That node could become the home location for my repo. My agents in Europe would send writes there. An agent in Australia working on the same repo could also send its writes to “Rizel’s European home node”. Entire would not have to operate the home infrastructure.
This option to self-host is an option; not a mandate. I see this option as ideal for users and organizations that care deeply about data privacy, ownership, security, and control over where their code lives.
As a result, it would also reduce the amount of traffic hitting Entire’s own infrastructure because companies could use their own servers to support their own agents.
Beyond Code Hosting
Entire’s vision goes beyond hosting code. We’re building an ecosystem to help humans and agents actually build together. Months ago, we already released Sessions and Checkpoints, features that track agent sessions. As you make a commit, Entire captures the transcript, tool calls, files changed, and more so you can understand the reasoning behind the code. This is because we don’t often know or remember why an agent made such a huge code change and the diff doesn’t reveal much beyond the lines of code changed.
Many people have asked me: "Why would I want to record my agent’s session history? I’m not going to go back and read it."
However, I’ve found this method helpful because I’m not necessarily reading through the transcript line by line, but I tell my agent to use the agent history to give me answers to questions I have like: why was this decision made. I don’t have to guess why a change happened because I just ask Entire.
But this collection of agent session history is only the foundation for our vision of a semantic reasoning layer directly tied to version control history, giving every agent persistent, shared, and pluggable memory.
The Future of the SDLC
We are participating in a fundamental shift in how software is written. The tools that got us through the last fifteen years of human-only development simply cannot support the next fifteen years of agent-human collaboration.
When you hear me say we are rebuilding "GitHub for the era of agents," it is a shorthand to help you visualize the scale of our vision. We are not literally cloning GitHub. Simply copying pull requests, issues, and wikis onto a new host does not solve the friction of human-agent collaboration.
Instead, Entire is introducing new primitives: building the native infrastructure for an agent-first software development lifecycle.
The agentic era is here. It is time our developer tools caught up.
Top comments (0)