A Version Control Repository That Speaks Git, Artifacts
Key point
Cloudflare unveiled Artifacts, a version-controlled filesystem built for the agent era.
Details
Artifacts is a version-controlled filesystem that lets you quickly spin up independent repositories for each execution environment—agents, sandboxes, Workers—and work with them directly using a regular Git client. It also provides a REST API and native Workers API, so even in environments without a Git client, you can automate repository creation, credential issuance, and commit operations.
The core goal is not to build traditional source control, but to create an agent-first storage primitive. Cloudflare sees agents as generating, modifying, and forking far more code and state than humans do, and believes a new base unit is needed to handle countless repos and session states.
Artifacts leverages Git's data model as-is. It splits objects to be stored into commit/history units, allowing revert, diff, fork, and time travel when needed—so it can handle not just code but also state like session prompts, session history, and per-customer config.
The main usage patterns are as follows.
- Create a repo with
env.AGENT_REPOS.create(name), receive a token and remote, and pass them to the agent - Connect like a regular Git remote using
git clone https://x:${TOKEN}@... - Import an existing GitHub repo with
env.ARTIFACTS.import()and fork it independently - Separate review or experimental branches into a read-only fork
Internally, Cloudflare maintains an Artifacts repo per agent session, keeping sandbox state and session history together. This eliminates the need to maintain separate block storage, and even without commits, you can view prompt state and file state together to share sessions or roll back to a specific point in time.
The implementation is built on top of Durable Objects. Each repo maps to a single Durable Object, and files are stored in SQLite-based storage. Due to the Durable Object's 2MB row size limit, large Git objects are split across multiple rows, and auth token management uses KV.
The Git engine was newly written in Zig and compiled to Wasm. SHA-1, zlib inflate/deflate, delta encoding/decoding, pack parsing, and the smart HTTP protocol were all implemented from scratch, with the native build used for testing against libgit2. The WASM and JS host are connected via 11 storage imports and 1 emit function, and both fetch and push operate on a streaming basis.
Protocol support is broad as well.
- Supports Git protocol v1/v2
- Supports
ls-refs, shallow clone, incremental fetch, and have/want negotiation - Native support for
git-notes, enabling storage of metadata like prompts and agent attribution
To solve the large-repo problem, ArtifactFS was also open-sourced. It's a blobless clone that fetches tree and refs first, then progressively hydrates file contents in the background. Priority files like package.json and go.mod are fetched first, unfinished files block until an agent tries to read them, and it works with external Git remotes like GitHub or GitLab as well.
Going forward, more metrics, repo-level event subscriptions, TypeScript/Go/Python SDKs, a repo/namespace search API, and a Workers Builds API are planned. Pricing is based on operations at $0.15/1,000, and storage at $0.50/GB-mo, designed with agent usage patterns in mind—large-scale but with many idle repos.
This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.
Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.