Skip to content

SYSTEM Cited by 1 source

ArtifactFS

ArtifactFS (github.com/cloudflare/artifact-fs) is Cloudflare's open-source filesystem driver that mounts a Git repository as a local filesystem with blobless-clone-plus-background-hydration semantics — "git clone but async". Announced alongside Artifacts on 2026-04-16.

"It's ideal for agents, sandboxes, containers and other use cases where startup time is critical."

Importantly, ArtifactFS works with any Git remote — GitHub, GitLab, self-hosted Gitea / GitLab / etc. It is not Artifacts-exclusive.

What it does

  1. Run a blobless clone of the target Git repository (fetches the file tree + refs, but not file contents) during sandbox / container startup. This lets the agent harness start working on the tree immediately without waiting on bytes.
  2. Concurrently, a lightweight daemon hydrates file contents in the background — downloading actual blobs from the Git remote and landing them in the filesystem.
  3. Reads on yet-to-be-hydrated files block until that file has been hydrated (the FS provides the transparent on-demand-fetch semantics).
  4. No sync-back: ArtifactFS does not attempt to reconcile local edits to the remote — it relies on the agent / developer running a normal git commit + git push. The post explicitly justifies this:

    "The filesystem does not attempt to 'sync' files back to the remote repository: with thousands or millions of objects, that's typically very slow, and since we're speaking git, we don't need to. Your agent just needs to commit and push, as it would with any repository. No new APIs to learn."

Agent-aware hydration priority

Hydration order is explicitly tuned for what agents typically want to operate on first:

  1. Package manifests — package.json, go.mod, pyproject.toml, Cargo.toml, etc.
  2. Configuration files — .yaml, .toml, .json.
  3. Source code — text files in known language extensions.
  4. Binaries / large blobs — images, executables, non-text files deprioritised where possible.

This is a specialisation of concepts/async-clone-hydration: the non-blocking boundary sits at the tree/refs ↔ blob-contents cutline, and priority within the blob-contents backlog is driven by what an agent's opening actions are likely to read.

Startup-latency claim from the post

"A popular web framework (at 2.4GB and with a long history!) takes close to 2 minutes to clone. A shallow clone is faster, but not enough to get down to single digit seconds, and we don't always want to omit history (agents find it useful). Can we get large repos down to ~10-15 seconds so that our agent can get to work? Well, yes: with a few tricks."

"If you can shave ~90-100 seconds off your sandbox startup time for every large repo, and you're running 10,000 of those sandbox jobs per month: that's 2,778 sandbox hours saved."

Caveat: these numbers are illustrative scaling of a single worked example; not a benchmarked fleet result.

How it relates to Artifacts

  • Artifacts is the server; ArtifactFS is the client-side FS driver. They are independently useful:
  • Artifacts without ArtifactFS: ordinary git clone of an Artifacts repo works like any Git remote.
  • ArtifactFS without Artifacts: mount a GitHub / GitLab / self-hosted repo with async hydration for faster sandbox startup.
  • Sharing the cloudflare/artifact-* namespace is the naming signal; the tools are designed to compose but each stands alone.

Seen in

Last updated · 200 distilled / 1,178 read