{"slug": "entire-launches-distributed-git-network-for-global-code-hosting", "title": "Entire Launches Distributed Git Network for Global Code Hosting", "summary": "Entire launched a distributed Git network designed for the agent era, handling ~570,000 clones per hour and 586 pushes per second on a single repository at ~50-60 ms p50 latency. The preview is live with mirrors in the US, EU, and Australia, and the Git backend is open source. This infrastructure aims to solve rate-limiting and throttling issues faced by coding agents operating at scale.", "body_md": "Centralized Git was always going to break under agent load. The protocol that Linus shipped in 2005 was designed for a handful of humans running `git push`\n\nfrom a coffee shop — not a swarm of coding agents each running shallow-clone → edit → push in a tight loop, thousands of times an hour, against the same repository. By 2026, that constraint is showing up as GitHub rate-limit emails, flaking CI, and \"the agent pool is throttled\" Slack messages. The fix has been talked about for years — mirror traffic, push to CDN, fan out the read side — but nobody had shipped it as a product with public numbers.\n\n[Entire just shipped the first credible answer](https://varindia.com/news/entire-launches-distributed-git-network-for-the-agent-era). The preview of their distributed Git network is live under waitlist, with active mirrors in the US, EU, and Australia, and the numbers from the initial test run are the first real evidence that the agent era has a Git backend it can grow into: **~570,000 clones/hour**, **586 pushes/second** (~2.1M/hour), and a sustained **~470 clone+push ops/sec** on a single repository at ~50–60 ms p50 latency. The Git backend itself is going open source. If you've been waiting for the infrastructure story to catch up to the agent story, this is it.\n\nA single central server per repository is a rate limit dressed up as a feature. When you have a hundred agents — let alone the \"billions\" the industry keeps waving at — all cloning and pushing into the same repo, you stop being able to pretend that GitHub is the canonical bottleneck. You start being one abuse-detection false positive away from a multi-hour outage.\n\n[[DIAGRAM: an agent fleet cloning from and pushing to a regional mirror in front of the GitHub origin — the mirror absorbs the read traffic, the origin stays untouched, pushes coalesce at the mirror]]\n\nEntire's premise is simple: keep the source of truth where it is (GitHub, for now), and put a regional mirror in front of it that agents can hammer without either side getting rate-limited. The origin keeps its existing CI, its existing webhooks, its existing access controls. The mirror takes the read load and the concurrent push pressure, and it does that for every region that needs it.\n\nThree things ship in the preview:\n\nThe next two milestones, per the announcement: native repository hosting (so you don't need GitHub as the origin at all) and a fully decentralized network where you can run your own region for data residency and sovereignty. Those are the parts that matter for enterprises that can't put their code on a US-hosted server for regulatory reasons — but the preview is what unblocks the agent workload today.\n\nFrom the initial test run, the announcement lists three concrete benchmarks. All on a single repository.\n\n| Operation | Throughput | Workload |\n|---|---|---|\n`git clone` (shallow) |\n~570,000 / hour | 200 simulated clients in Frankfurt (40%), Paris, London, Dublin — 3 min |\n`git push` |\n586 / sec (~2.1M / hour) | 128 simulated agents, 1–10 files @ 2 KB each, 2 min, one branch per agent |\n| clone + push (mixed loop) | ~470 / sec | 128 agents running shallow clone → 5 pushes → repeat, ~50–60 ms p50 |\n\nThe mixed-loop number is the one to circle. 470 clone+push ops/sec at 50–60 ms p50 is what an agent actually does — pull, work, push, repeat — and that's the workload traditional Git hosting wasn't designed for. 200 clients pulling shallow clones in parallel is also roughly what a 50-engineer team with aggressive CI looks like on a busy day, before you add agents to the mix.\n\n[[CHART: a relative comparison of clones-per-hour, pushes-per-hour, and mixed-ops-per-second on one repository — order of magnitude, not exact]]\n\nThe preview is gated behind a waitlist. The good news is the integration is small:\n\n```\n# 1. Join the waitlist at entire.io (link in the launch post)\n# 2. Approve → connect your GitHub account via the Entire dashboard\n# 3. Pick the repos you want mirrored\n# 4. Choose the regional mirror closest to your agent fleet (us, eu, au)\n\n# Point your agents at the regional mirror\ngit clone \n\n# Origin stays on GitHub — your existing CI, webhooks, deploys don't change\n# Mirror is read-heavy on clone, write-through on push\n\n# For an existing clone, swap the remote:\ngit remote set-url origin\n```\n\nThat's the whole integration. For anything that already supports a custom Git remote — Cursor, Claude Code, Aider, custom harnesses, your CI runner — it's a one-line config change per remote. If you're running a fleet of agents in a single region, point them at the closest mirror. If you're running agents in multiple regions, the dashboard picks the mirror per clone, and your Git origin stays where it's always been.\n\nThe day-to-day operational change is also small. Pulls are faster. Pushes coalesce at the mirror so you're not opening N connections to GitHub per agent. And when GitHub's rate limiter does fire — and it will, for some agent workload, eventually — your fleet is reading from the mirror, not the origin, and the only thing that notices is the push queue.\n\nThe numbers are impressive but they aren't the most interesting part. The most interesting part is at the end of the announcement: Entire is going to open source the Git backend.\n\nRead that again. The same backend that just hit 570k clones/hour and 586 pushes/sec on a single repo is going to ship with a license you can read, fork, and self-host. If you've ever tried to scale Git at the protocol level — every team that runs GitHub Enterprise at non-trivial size has, at least once, rage-Googled \"git protocol scalability\" — you know that this is the layer everyone wants to tweak and almost nobody can.\n\nCombine an open backend with the upcoming native hosting and full decentralization, and the long-term shape is clear: any team can run its own region, on its own infrastructure, in its own jurisdiction, and the network still functions. Linus said it in 2007 at Google: \"If you're not distributed, you're not worth using.\" The preview is the first step toward an implementation that actually matches that statement at production scale.\n\nThree things the announcement doesn't paper over:\n\nNone of these are reasons to skip it. They're reasons to know what you're signing up for before you migrate your agent fleet onto a preview.\n\nEntire is solving the \"where the code lives\" problem. The mirror is the part that changes; the code is the part that doesn't. OTF solves the same shape of problem on the other side of the stack: the source of truth is one codebase, and the surface — web, iOS, Android — is many.\n\n[[CONCEPT: one source of truth, many surfaces — a single component definition rendered identically across web and mobile, the same way a single Git repo is read identically from any region]]\n\nWhen you ship a product that has to behave the same way on three platforms and survive a year of agent-driven refactors, the durable layer is the one that doesn't have to change every time the infra changes. The Git host changes — mirror goes from one region to three, then to native, then to fully decentralized. The model behind your agent changes. The component on the screen stays the same, and that's the part your users actually feel.\n\nUse Entire, and you've freed your agents to work as fast as the network will let them. The thing you put in front of your users is the part that needs to be just as durable — and that's the part OTF is built to be.\n\nThe preview is small, the waitlist is the only friction, and the integration is a URL swap. If you have an agent fleet that's already outgrown GitHub's rate limits, this is the first backend that's been built for the workload you're actually running — and the open-source promise is the part that turns it from a product into infrastructure.", "url": "https://wpnews.pro/news/entire-launches-distributed-git-network-for-global-code-hosting", "canonical_source": "https://dev.to/davekurian/entire-launches-distributed-git-network-for-global-code-hosting-5b59", "published_at": "2026-07-09 16:08:07+00:00", "updated_at": "2026-07-09 16:35:52.046607+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "ai-agents"], "entities": ["Entire", "GitHub", "Linus Torvalds"], "alternates": {"html": "https://wpnews.pro/news/entire-launches-distributed-git-network-for-global-code-hosting", "markdown": "https://wpnews.pro/news/entire-launches-distributed-git-network-for-global-code-hosting.md", "text": "https://wpnews.pro/news/entire-launches-distributed-git-network-for-global-code-hosting.txt", "jsonld": "https://wpnews.pro/news/entire-launches-distributed-git-network-for-global-code-hosting.jsonld"}}