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 has done an amazing job for almost two decades. It also has established and well-loved alternatives like GitLab and Bitbucket. There's also a new wave of git hosting competitors popping up that are tackling the solution from different angles. For example:
- Tangled is focused on federated, social hosting using the AT Protocol.
- Cursor Origin is building an AI-native forge to handle heavy agent traffic.
- Gitlawb is leaning into decentralized agent identity.
So, which architecture actually makes sense for the future?
My answer is ripe with bias, but I truly believe Entire is the git hosting platform that will matter in the end.
That's because we aren't trying to rebuild GitHub 1:1 or just make a clone of it. Simply copying existing features onto a new host doesn't solve the friction of how humans and AI agents need to work together. We are building something fundamentally different.
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 whole 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, major git hosting platforms have been having outages and performance issues. It’s becoming an expected part of the developer experience. It is widely acknowledged across the industry that AI and automated traffic is a major factor behind these reliability issues.
Before I joined this company, I noticed that many platforms and apps were down or buggy, so I blamed it on companies leaning too heavily into vibe coding, creating bugs that caused systems to crash. But for the case of git hosting problems, the culprit is agent traffic.
Traditional git hosting 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.
Traditional Code Hosting is Centralized
Traditional platforms store data in central servers by default, meaning the majority of global developer traffic goes directly to a primary cluster of data centers.
This central 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 this infrastructure is a replication system that 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.
Traditional platforms also use Points of Presence, or PoPs, around the world. A PoP is mainly an entrance into the hosting network. It helps route the request, but the full repository operation is completed by the central 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 PoP. The PoP routes the traffic to the provider's central network. When it gets there, that central network is chugging along processing API requests, searches, and git commands on many servers in parallel.
The PoP says: "Hey, Rizel’s agent wants to put up this PR."
The central cluster 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, the infrastructure 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
At Entire we thought of a solution: 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 a centralized network, Entire can run the storage and Git services needed to serve a repository directly from Europe. That way, if you are in France, you can choose Europe as your region and let your 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 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.
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)