Hosting Git on Cloudflare: What the Smart HTTP Protocol Actually Requires

If you run Gitea or Forgejo on a VPS, the practical answer to “can Cloudflare carry my Git hosting?” is that Cloudflare itself does not claim Workers can serve Git’s protocol. Its October 1, 2026 announcement concedes the point. Rather than asking you to implement the protocol on Workers, it points you to Artifacts, the Git-speaking versioned storage Cloudflare launched earlier this year, and invites you to build the platform layer above it. Cloudflare’s post is the only source cited here for these capabilities, and no independent measurements accompany it, so treat its performance and capacity statements as vendor claims until third-party numbers exist. That caveat matters because the interesting question is not whether an edge network can store repositories, but which component owns each operation of Git’s smart HTTP protocol, and where the protocol’s known costs land when the execution model is serverless.

The timing is real, though. Cloudflare’s announcement is a competition invitation: “Now that Artifacts is in open beta, we’re holding a competition to see who can build the next Git platform on Cloudflare using Workers and Artifacts.” Submissions close October 14, 2026, and Artifacts billing starts October 15, 2026, according to the same post. Anyone weighing a migration has roughly one week before Artifacts usage starts billing, so the feasibility question is immediately practical.

What Cloudflare announced, and what it did not

The headline framing deserves a correction first. The announcement names two products: Workers and Artifacts. R2 and Durable Objects appear nowhere in the announcement text, and Cloudflare’s own R2 product page lists Artifacts as a separate product described as Git-native versioned storage rather than a feature of R2. So this is not an invitation to hand-implement smart HTTP on raw Workers plus object storage. It is an invitation to build the coordination and product layer on top of a storage substrate Cloudflare has already built.

What Artifacts provides, per the announcement:

• A versioned filesystem that “speaks Git and can scale to millions of repositories,” in open beta and available only on the Workers Paid plan.
• An Artifacts binding for Workers that can create or fork repositories, inspect files and commits, and issue repo-scoped Git tokens.
• Event subscriptions firing whenever a repository is created, imported, forked, deleted, pushed to, cloned, or fetched.
• Namespace pinning to U.S. or EU data jurisdiction.
• Deploy-on-push integration: Workers Builds deploys production branches on push, with other branches producing Workers Previews.

Pricing is based on repository operations and data stored, with billing beginning October 15, 2026, per the same post. What the post does not provide: a consistency model specification, throughput or CPU numbers for pack generation, or any benchmark. Those absences are the substance of the rest of this article.

What serving Git actually costs the server on every request

Git’s smart HTTP protocol looks stateless from the client’s side: a fetch is a couple of HTTP requests. The server’s side is neither stateless nor cheap. Uber’s GitFarm paper, a production account of a Git-execution service for large monorepos, puts the cost plainly: “Each request still requires the upstream Git server to enumerate objects, generate packfiles, and stream compressed data to the client. As the number of clients grows, this repeated work increases server-side CPU and I/O load, and becomes a bottleneck.”

Unpack the three operations. Object enumeration means walking the commit graph to compute what the client already has versus what it needs, which is the negotiation phase of fetch and push. Packfile generation means collecting the resulting objects, computing deltas, and compressing them into a pack. Streaming means pushing that pack out while the client reads it. All three happen per request, per client, and Git’s own documentation (cited by GitFarm as Chacon and Straub, 2024; Git Project, 2024a) describes the same server-side work. These mechanics rest on GitFarm’s operational account and its citations to Git’s own documentation, not on the smart HTTP protocol specification itself.

How expensive can this get? GitFarm’s example is extreme but instructive: cloning Uber’s Go monorepo takes about 15 minutes and consumes roughly 4 CPU cores, 16 GB of memory, and more than 40 GB of disk, according to the paper. A small private repository is nowhere near that, and you should not size a side-project forge off Uber’s monorepo. But the shape of the cost is the same at any size: CPU and I/O concentrated at the moment of each fetch, growing with concurrent clients.

This is exactly the kind of workload serverless functions fit worst: stateful, CPU-heavy, long-running, and per-request. The closest measured comparison is an IoT platform migration study, and it runs into the same wall before it can even start: the authors migrated only the platform’s stateless REST endpoints and HTTP gateway onto OpenWhisk and Google Cloud Run, left MariaDB, Kafka and Elasticsearch on a separate Kubernetes cluster, and could not move the WebSocket and MQTT gateways at all, because those protocols “are inherently stateful which prevented their adaption into OW and GCR functions.” Git was not the workload. Still, the database-backed endpoints offer a signal. On the Sensors-Get endpoint under linear load, the GKE-80 deployment served 343,343 requests within a 19.63ms p(95) response time, the study reports, while the OpenWhisk deployment served 161,053 requests within 94.15ms p(95). The paper attributes OpenWhisk’s collapse under peak concurrency to the overhead of sequencing functions, and its early Cloud Run latency spikes to cold starts. The exception matters as much as the rule: on the stateless HTTP gateway, OpenWhisk served 322,721 requests at a 39.33ms p(95), beating both GKE configurations, per the study. So keep the lesson narrow. An IoT platform is not a Git pack negotiation, and these numbers are directional evidence about execution models, not Git benchmarks. But where every request touches shared state, the function deployments paid a real p(95) penalty, and a Git fetch is that shape.

The consistency problem: refs, objects, and what object stores do not give you

CPU cost is the obvious objection. Consistency is the one that can silently corrupt a repository. A Git push is a ref update that must be atomic and correctly ordered against other pushes; lose that, and you get non-fast-forward chaos, lost objects, or garbage collection deleting something a ref still needs.

Production Git hosts treat this as non-negotiable. GitFarm’s summary, from the same paper, is worth quoting at length: GitHub’s Spokes and GitLab’s Gitaly Cluster “horizontally scale Git hosting by replicating repositories across backend nodes and distributing client traffic. While these designs improve aggregate throughput, they still require strong consistency among replicas to preserve object integrity, reference correctness, and garbage collection semantics.” Even systems built by companies with enormous infrastructure budgets replicate stateful nodes and pay for coordination rather than going stateless.

GitFarm itself makes a deliberate trade: each backend node holds a single on-disk bare clone per repository, kept fresh by push-based event sync plus a git fetch every five minutes, and the system exposes eventual consistency with the upstream alongside per-request freshness control, according to the paper. Notice what Uber did not do: it did not put repositories in an object store and serve them from stateless functions. It put long-lived clones on disks and engineered around the freshness gap explicitly.

The independent research on object stores sharpens the concern. VICOS, a research system for integrity and consistency on cloud object stores, starts from the position that commercial object stores should be verified rather than trusted; per its evaluation, that protection cost about 20% in overhead for high-throughput accesses in the prototype. That is a research prototype, not a measurement of Cloudflare’s infrastructure, and it does not prove Artifacts has a consistency problem. What it establishes is that “objects in a store” and “objects with verifiable integrity and consistent reads” are different products, and the difference has a real price. The open question for Artifacts is which product you are getting, and the announcement does not say.

Mapping the protocol to the infrastructure

The useful way to evaluate any Git hosting design is operation by operation. Here is how the pieces map, and where the documentation runs out.

Negotiation (ref advertisement and have/want exchange). Whoever terminates the Git protocol owns this. On a VPS forge, Gitea or Forgejo does it in the same process as everything else. On Cloudflare, the announcement implies Artifacts terminates Git protocol operations, since Workers interact with repos through bindings and tokens rather than by serving pack streams themselves; but the post does not describe the termination architecture, so this is inference from the announcement’s feature list, not a documented fact.

Pack generation. The per-request CPU/I/O cost identified by GitFarm. If Artifacts absorbs this inside its storage layer, the Workers CPU-time objection largely disappears for builders, because your Worker never generates a pack. If any part of it leaks into your Worker, Workers CPU-time limits become your problem, and the announcement says nothing about them. This is the first thing to test.

Ref updates and concurrent push correctness. This is where strong consistency is required, per GitFarm’s account of Spokes and Gitaly. On a single-VPS forge, one process serializes ref updates against one disk, which is boring and correct. Under Artifacts, correctness depends on a consistency model the announcement does not describe.

Permissions. Here Cloudflare’s offering is genuinely well-specified: repo-scoped Git tokens issued from Workers, per the announcement. A self-hosted forge gives you fuller access-control machinery but also makes you the operator of it.

One row deserves emphasis: the hand-rolled column is a straw man Cloudflare itself avoids. If your plan was “smart HTTP on Workers plus R2 plus Durable Objects,” you would be rebuilding the hardest parts, pack generation and ref consistency, that even GitHub and GitLab solve with stateful replicated nodes.

The economics: zero egress meets per-operation billing

The storage-side pitch is familiar and real: R2 markets zero egress fees, S3-compatible APIs, and a native Workers binding, per Cloudflare’s R2 page, and Cloudflare’s network is large by its own account, a self-reported 115 million HTTP requests per second from 335 cities per its about page. For read-heavy repository traffic, zero egress is a genuine economic advantage over a VPS whose bandwidth you meter or a cloud that charges egress.

But Artifacts does not bill like R2. It bills on repository operations plus data stored, starting October 15, 2026, per the announcement. Git is an operation-generating machine: every clone, fetch, and push from every developer and every CI runner is billable. The economics question inverts. On a VPS, your thousandth CI fetch of the day is free; on a per-operation model, it is a line item. Whether that works out cheaper depends on per-operation prices the announcement does not include, so model your own fetch/push volume against the prices Cloudflare publishes once billing starts rather than assuming edge economics automatically win.

What to verify before moving private repositories

Before moving anything you cannot afford to lose, verify three things: Artifacts’ consistency and integrity guarantees in writing (ref update atomicity under concurrent push, object verification, GC behavior); pack-generation performance under your repository sizes and CI concurrency, since the announcement gives no throughput or CPU numbers for pack generation; and the post-October-15 per-operation pricing against your measured operation volume. Also keep beta status in view: Artifacts is open beta on a paid plan from a single vendor, and terms announced one week ago are not a stable foundation.

Where each option wins

My read, stated as a judgment with its conditions: if you are building a code-hosting product or agent-facing repository features, build on Artifacts and let it own fetch and push. Cloudflare has already done the part that production experience says is hard, and the bindings, tokens, events, and jurisdiction controls are a real coordination layer, not vapor. I would not hand-roll the protocol on raw Workers and object storage; that path puts the strongest consistency requirements in Git hosting on the component least equipped to provide them.

If you are deciding where existing private repositories live, the calculus is narrower. Where correctness under concurrent push is non-negotiable and your team’s VPS already handles the load, a self-hosted forge remains the evidence-backed choice: its cost profile is fixed, its consistency story is one process and one disk, and nothing in the announcement addresses the questions that would justify migrating. Revisit when Artifacts publishes a consistency model and survives a few months of billing. The invitation will still be there; the burden of proof is still Cloudflare’s.

Frequently Asked Questions

When does Artifacts billing start?

Submissions close October 14, 2026, and Artifacts billing starts October 15, 2026, according to the same post.

What does Artifacts cost?

Pricing is based on repository operations and data stored, with billing beginning October 15, 2026, per the same post.