On 1 October, Cloudflare opened a competition: build the next Git platform on Workers and Artifacts, its Git-compatible storage layer. First prize is $25,000 in Cloudflare credits, and submissions close on 14 October. The company’s own changelog puts it more bluntly than the blog post does: “Build the next GitHub on Cloudflare.”
That framing invites a specific mistake. We read the Artifacts documentation and measured thirty real repositories against its published limits, and those limits describe a different product from the one the headline implies. Artifacts is excellent at what it is actually for. It is not a place to put your repository.
TL;DR
- Cloudflare’s own best-practice guidance reads: “If you have
10,000agents, create10,000repos.” The documented ceiling is 1 GB of storage per repository and 1 TB per account. - We measured 30 widely-used GitHub repositories. 13 of 30 already exceed the 1 GB per-repository cap, and the median was 809 MB. Odoo is 17.13 GB, roughly seventeen times the limit.
- The 32 MB blob cap is not the binding constraint. Zero of the 30 had a file over 32 MB in their current tree. The largest we found was 22.9 MB.
- Three independent signals say Artifacts is not meant to hold full history: the 1 GB cap, the fact that Git’s
filtercapability (partial clone) is not supported, and Cloudflare’s own import example, which passes"depth": 100. - On a fork-per-task workload, operations cost almost nothing and storage is the entire bill. Our model came to $6.00 of operations against $3,948 of storage. Deleting forks after a day cut that to $131.
- The documentation never states how fork storage is billed. It explicitly exempts replicas and says nothing about forks. That silence is the largest single unknown before billing starts.
The guidance, verbatim
Artifacts creates isolated Git repositories on demand, each with its own remote URL, scoped tokens and durable state, routed from any region in the same way as a Durable Object.
The recommended pattern is unambiguous. From the best practices page: “Create one repo for each unit of autonomous work. If you have 10,000 agents, create 10,000 repos.” The same page tells you not to use one shared repository as a queue for many autonomous agents.
That is a good design for agent fleets, and the opposite of how GitHub is used. Be precise about which of the two you are building, because the published limits only accommodate one.
What we measured
We took thirty well-known repositories, the sort an agent fleet would plausibly be pointed at, and pulled each one’s size and a recursive tree listing from the GitHub API. Against the 1 GB per-repository ceiling:
- 13 of 30 exceed 1 GB: Odoo 17.13 GB, Nextcloud Server 6.93 GB, the Linux kernel 6.10 GB, Next.js 2.46 GB, Supabase 2.37 GB, Grafana 1.95 GB, Godot 1.81 GB, Elasticsearch 1.71 GB, Node.js 1.57 GB, PyTorch 1.55 GB, VS Code 1.46 GB, Kubernetes 1.46 GB and React 1.05 GB.
- The median repository was 809 MB, which is 79% of the cap. React, at 1.05 GB, is the closest to the line.
Two honest caveats. GitHub’s size field is its own hourly on-disk figure, not a push-size guarantee; we cross-checked three repositories with a real git clone --mirror and the two metrics disagreed by between -5% and +46%. The tree listing was also truncated by the API for four repositories, so the blob result below is a floor rather than a proof. Neither touches the headline, because the repositories over the cap are over it by far more than the measurement error.
The cross-check surfaced a migration trap. A --mirror clone pulls refs/pull/*, and GitHub has a lot of those: 3,652 on Express, 7,311 on Vue core, and 45,168 on the Laravel framework. Laravel goes from 104 MB by GitHub’s reckoning to 151 MB as a mirror, carrying pull-request refs you almost certainly do not want in an agent workspace. The obvious migration command inflates you towards a hard ceiling before you have written anything.
The blob cap is a red herring
We expected the 32 MB per-file limit to bite. It did not. Across the 30 repositories, not one had a file over 32 MB in its current tree. The largest we found anywhere was a 22.9 MB register-definition header in the Linux kernel’s AMD GPU driver.
That is a useful negative result. The file-size limit is generous. The repository-size limit is the wall.
Three signals, one conclusion
The 1 GB cap is not an isolated number. Two other details in the documentation point the same way.
First, Artifacts supports Git protocol v1 and v2 for clone and fetch, but the docs state that “some optional v1 capabilities, such as filter and include-tag, are not supported.” The filter capability is partial clone, the mechanism you would use to work against a large repository cheaply, and exactly what a fleet of short-lived agents wants. Shallow and deepen fetches do work, so --depth is available and --filter=blob:none is not.
Second, Cloudflare’s own documented way to bring an existing repository in is a shallow import: the example in the import guide passes "depth": 100. The reference implementation does not bring your history. In the same spirit, fork() takes a defaultBranchOnly option, and every example in the best practices page sets it to true.
Read together, these are not shortcomings. They are a product telling you what it is: a substrate for short-lived, isolated working copies, not a system of record, and the same reasoning applies to Durable Objects. The risk is in the branding, because “the next GitHub” and “ten thousand disposable agent workspaces” need very different things from storage.
The bill is storage, and one term is missing
Pricing, published on 1 October, is two-dimensional on the Workers Paid plan: operations at the first 10,000 per month free then $0.15 per additional 1,000, and storage at the first 1 GB free then $0.50 per GB-month, averaged from daily peak.
We modelled Cloudflare’s own figure of 10,000 agents, each forking the median 809 MB repository, with a fork, a clone and three pushes per task. Operations come to 50,000, of which 40,000 are billable, for $6.00. Storage, if nothing is ever deleted, comes to 7,898 GB for $3,948 per month. Operations are 0.15% of that bill.
Delete each fork after a day and the average daily peak falls to 263 GB, or $131 per month. The same workload, a thirty-fold difference, decided entirely by whether you call delete. The pricing page is explicit that repositories “remain stored until you explicitly delete them”, so in a fork-per-task architecture, cleanup is not hygiene. It is the budget.
There is a larger problem hiding in that arithmetic. Ten thousand repositories at 809 MB each is 7.7 TB, against a default account ceiling of 1 TB. To follow the ten-thousand-repo guidance inside that cap, your average repository must come in under 105 MB. Three of our thirty did. The cap can be raised on request, but know that you will be asking.
And the term we could not fill in: how is a fork billed? We searched the complete Artifacts documentation set, all 207 KB of it. The word “fork” never appears next to storage, billing or cost. The pricing page explicitly exempts one thing, replicas, and says nothing about forks. We are not claiming forks are billed as full copies, because the documentation does not say either way. We are saying it is the dominant term in the bill and it is undocumented, so get an answer in writing first. Note the deadline carefully: the announcement post says billing begins on 15 October, while the documentation says the 14th in three separate places. On the documentation’s date, the meter starts the same day submissions close, on a product with no free tier.
What we would do with this
If you are considering Artifacts for production, three questions decide it. Is your unit of work a repository or a task? If it is a repository, measure it first, because our sample says there is a 43% chance it does not fit. Does the workflow need history, or just a working tree at a known commit? If just a tree, the cap stops mattering. And who owns the delete call, because that is a thirty-fold swing in the monthly bill and it will not show up in any load test.
This is the kind of decision we make with clients regularly: reading a platform’s limits rather than its launch post, and working out which product the constraints describe. We build on Cloudflare Workers, run agent infrastructure in production, and have tested Git tooling against its edge cases before. If you are weighing up an agent-native architecture and want the arithmetic checked before you commit, get in touch.
Measurements taken 5 October 2026 against the GitHub REST API and the Artifacts documentation as published on 1 October 2026. Limits on a product in open beta will move, and the method is a dozen API calls, so re-run it before relying on it.
📷 Photo by OSG Containers on Unsplash
