Artifacts: versionierter Speicher, der Git spricht

Agenten haben verändert, wie wir über Versionsverwaltung, Dateisysteme und das Persistieren von Zuständen denken. Entwickler und Agenten erzeugen mehr Code als je zuvor — in den nächsten fünf Jahren wird mehr Code geschrieben werden als in der gesamten bisherigen Geschichte der Programmierung — und das hat zu einem sprunghaften Größenwachstum der Systeme geführt, die zur Deckung dieser Nachfrage erforderlich sind. Besonders Plattformen für die Versionsverwaltung geraten hier an ihre Grenzen: Sie wurden für die Bedürfnisse von Menschen gebaut, nicht für eine Verzehnfachung des Volumens durch Agenten, die nie schlafen, gleichzeitig an mehreren Aufgaben arbeiten können und niemals ermüden.

Wir sind der Ansicht, dass es einen neuen grundlegenden Baustein braucht: ein verteiltes, versioniertes Dateisystem, das in erster Linie für Agenten entwickelt wurde und die heute entstehenden Anwendungstypen unterstützen kann.

Wir nennen das Artifacts: ein versioniertes Dateisystem, das Git spricht. Sie können Repositories programmatisch erstellen – zusammen mit Ihren Agenten, Sandboxes, Workers oder jedem anderen Compute-Paradigma – und sich mit jedem gewöhnlichen Git-Client damit verbinden.

Möchten Sie jeder Agentensitzung ein Repository zuweisen? Artifacts kann das. Jeder einzelnen Sandbox-Instanz? Auch das kann Artifacts. Sie möchten 10.000 Forks von einem bewährten Ausgangspunkt erzeugen? Natürlich geht das mit Artifacts. Artifacts stellt eine REST-API und eine native Workers-API bereit, um Repositories zu erstellen, Zugangsdaten zu generieren und Commits für Umgebungen zu erzeugen, in denen ein Git-Client nicht die richtige Wahl ist, also etwa in serverlosen Funktionen.

Artifacts ist für alle Entwickler mit einem kostenpflichtigen Workers-Tarif in der privaten Beta verfügbar. Wir wollen den Dienst bis Anfang Mai als öffentliche Beta verfügbar machen.

// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }

# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

Mehr ist es nicht. Ein Bare-Repository, sofort einsatzbereit, im Handumdrehen erstellt, und von jedem Git-Client nutzbar.

Und wenn Sie ein Artifacts-Repo aus einem bestehenden Git-Repository initialisieren möchten, damit Ihr Agent unabhängig daran arbeiten und eigenständige Änderungen pushen kann, dann ist auch das mit .import() möglich:

interface Env {
  ARTIFACTS: Artifacts
}

export default {
  async fetch(request: Request, env: Env) {
    // Import from GitHub
    const { remote, token } = await env.ARTIFACTS.import({
      source: {
        url: "https://github.com/cloudflare/workers-sdk",
        branch: "main",
      },
      target: {
        name: "workers-sdk",
      },
    })

    // Get a handle to the imported repo
    const repo = await env.ARTIFACTS.get("workers-sdk")

    // Fork to an isolated, read-only copy
    const fork = await repo.fork("workers-sdk-review", {
      readOnly: true,
    })

    return Response.json({ remote: fork.remote, token: fork.token })
  },
}

Sehen Sie sich die Dokumentation an, um loszulegen. Wenn Sie jedoch verstehen möchten, wie Artifacts eingesetzt wird, wie es entwickelt wurde und wie es unter der Haube funktioniert, lesen Sie weiter.

Agenten kennen Git. Es ist tief in den Trainingsdaten der meisten Modelle verankert. Sowohl der Standardfall als auch die Randfälle sind Agenten gut bekannt, und auf Code optimierte Modelle (und/oder Harnesses) sind besonders versiert im Umgang mit Git.

Darüber hinaus eignet sich das Datenmodell von Git nicht nur für die Quellcodeverwaltung, sondern für alles, bei dem Sie Zustände nachverfolgen, frühere Stände wiederherstellen und große Mengen kleiner Daten dauerhaft speichern müssen. Code, Konfigurationen, Session-Prompts und Agentenverläufe: All das sind Dinge („Objekte“), die Sie häufig in kleinen Einheiten („Commits“) speichern und zu denen Sie später zurückkehren oder auf die Sie zurückrollen möchten („Historie“).

Wir hätten ein völlig neues, maßgeschneidertes Protokoll entwickeln können … aber dann stößt man auf das Bootstrap-Problem. KI-Modelle kennen es nicht, also müssten Sie Skills verteilen, ein CLI bereitstellen oder hoffen, dass Nutzer an Ihr Docs-MCP angebunden sind … all das erzeugt zusätzliche Reibung.. Wenn wir Agenten stattdessen einfach eine authentifizierte, sichere HTTPS-Git-Remote-URL geben und sie so arbeiten lassen können, als wäre es ein Git-Repository, funktioniert das erstaunlich gut. Und für Clients, die kein Git sprechen – etwa einen Cloudflare Worker, eine Lambda-Funktion oder eine Node.js-Anwendung – haben wir eine REST-API und bald auch sprachspezifische SDKs bereitgestellt. Diese Clients können auch isomorphic-git verwenden, aber in vielen Fällen kann eine einfachere TypeScript-API die erforderliche API-Oberfläche verringern.

Die Git-API von Artifacts könnte den Eindruck erwecken, dass sie nur für die Quellcodeverwaltung gedacht ist, doch tatsächlich sind die Git-API und das Git-Datenmodell eine leistungsstarke Möglichkeit, Zustand so zu persistieren, dass sich beliebige Daten verzweigen, historische Stände wiederherstellen und miteinander vergleichen lassen.

Innerhalb von Cloudflare setzen wir Artifacts für unsere internen Agenten ein: Der aktuelle Zustand des Dateisystems und die Session-Historie werden automatisch in einem eigenen Artifacts-Repo pro Sitzung gespeichert. Dadurch können wir:

• Den Zustand von Sandboxes speichern, ohne Blockspeicher bereitstellen und dauerhaft vorhalten zu müssen.

• Sitzungen mit anderen teilen und ihnen erlauben, sowohl im Zustand der Sitzung (Prompts) als auch im Dateizustand in der Zeit zurückzureisen – unabhängig davon, ob es Commits in das „eigentliche“ Repository (die Quellcodeverwaltung) gab.

• Und das Beste: Eine Sitzung von jedem beliebigen Punkt aus forken, sodass unser Team Sitzungen mit Kolleginnen und Kollegen teilen kann und diese sie genau dort weiterführen können. Sie debuggen gerade etwas und möchten noch ein zweites Paar Augen darauf werfen? Senden Sie einfach eine URL und forken Sie die Sitzung. Sie möchten an einer API weiterfeilen? Lassen Sie einen Kollegen die Sitzung forken und dort weitermachen, wo Sie aufgehört haben.

Wir haben auch mit Teams gesprochen, die Artifacts in Anwendungsfällen nutzen möchten, in denen das Git-Protokoll überhaupt keine Voraussetzung ist, die Semantik dahinter – also Zurücksetzen, Klonen und Vergleichen – aber schon. Wenn Sie beispielsweise kundenspezifische Konfigurationen als Teil Ihres Produkts speichern und die Möglichkeit zum Rollback haben möchten, kann Artifacts dafür eine gute Repräsentation sein.

Wir freuen uns darauf zu sehen, wie Teams die nicht Git-zentrierten Einsatzmöglichkeiten von Artifacts genauso intensiv erkunden wie die Git-fokussierten.

Artifacts basieren auf Durable Objects. Die Fähigkeit, Millionen – oder sogar viele zehn Millionen – Instanzen zustandsbehafteter, isolierter Recheneinheiten zu erzeugen, ist bereits heute ein grundlegender Bestandteil der Funktionsweise von Durable Objects, und genau das brauchten wir, um Millionen von Git-Repositories pro Namespace zu unterstützen.

Major League Baseball (für die Live-Verteilung von Spielereignissen), Confluence Whiteboards und unser eigenes Agents SDK nutzen Durable Objects im Hintergrund in erheblichem Maßstab, und deshalb bauen wir hier auf einem Grundbaustein auf, den wir bereits seit einiger Zeit produktiv einsetzen.

Was wir allerdings brauchten, war eine Git-Implementierung, die auf Cloudflare Workers laufen kann. Sie musste klein, möglichst vollständig, erweiterbar (Notes, LFS) und effizient sein. Also haben wir eine in Zig gebaut und nach Wasm kompiliert.

Warum haben wir Zig verwendet? Drei Gründe:

1.  Die gesamte Git-Protokoll-Engine ist in reinem Zig geschrieben (ohne libc) und zu einer etwa 100 KB großen WASM-Binärdatei kompiliert worden (mit weiterem Optimierungspotenzial!). Sie implementiert SHA-1, zlib-Inflate/Deflate, Delta-Kodierung und -Dekodierung, Pack-Parsing sowie das vollständige Git-Smart-HTTP-Protokoll – alles von Grund auf neu und ohne externe Abhängigkeiten außer der Standardbibliothek.

2.  Zig gibt uns manuelle Kontrolle über die Speicherallokation, was in eingeschränkten Umgebungen wie Durable Objects wichtig ist. Das Zig-Build-System ermöglicht es uns, Code problemlos zwischen der WASM-Laufzeitumgebung (Produktion) und nativen Builds (zum Testen gegen libgit2 zur Korrektheitsprüfung) zu teilen.

3. Das WASM-Modul kommuniziert mit dem JavaScript-Host über eine schlanke Callback-Schnittstelle: 11 vom Host importierte Funktionen für Speicheroperationen (host_get_object, host_put_object usw.) sowie eine Funktion für Streaming-Ausgabe (host_emit_bytes). Die WASM-Seite lässt sich vollständig isoliert testen.

Im Hintergrund verwendet Artifacts auch R2 (für Snapshots) und KV (zum Tracking von Authentifizierungstoken):

^{So funktioniert Artifacts (Workers, Durable Objects und WebAssembly)}

Ein Worker fungiert als Frontend, übernimmt Authentifizierung und Autorisierung, erfasst zentrale Kennzahlen wie Fehler und Latenz und ermittelt jedes Artifacts-Repository (Durable Object) dynamisch zur Laufzeit. 

Konkret bedeutet das:

• Die Dateien werden in der zugrunde liegenden SQLite-Datenbank des Durable Objects gespeichert.

  • Der Durable Object-Speicher hat eine maximale Zeilengröße von 2 MB, sodass große Git-Objekte aufgeteilt und über mehrere Zeilen gespeichert werden.

  • Wir nutzen die synchrone KV-API (state.storage.kv), die im Hintergrund auf SQLite basiert.

• Durable Objects verfügen über Speicherlimits von etwa 128 MB. Das bedeutet, dass wir viele zehn Millionen davon starten können – sie sind schnell und schlank –, aber innerhalb dieser Grenzen arbeiten müssen.

  • Wir setzen sowohl beim Fetch- als auch beim Push-Pfad stark auf Streaming und geben dabei direkt einen `ReadableStream<Uint8Array>` zurück, der aus den rohen Ausgabeblöcken des WASM aufgebaut wird.

  • Wir vermeiden es, eigene Git-Deltas zu berechnen. Stattdessen werden die rohen Deltas und die Basis-Hashes zusammen mit dem aufgelösten Objekt persistiert. Beim Fetch gibt Zig das Delta statt des vollständigen Objekts aus, wenn der anfragende Client das Basisobjekt bereits besitzt, was Bandbreite und Speicher spart.

• Unterstützung für v1 und v2 des Git-Protokolls.

  • Wir unterstützen Funktionen wie ls-refs, flache Klone (deepen, deepen-since, deepen-relative) und inkrementelles Fetching mit Have/Want-Aushandlung.

  • Wir verfügen über eine umfangreiche Testsuite mit Konformitätstests gegen Git-Clients und Verifizierungstests gegen einen libgit2-Server zur Überprüfung der Protokollunterstützung.

Darüber hinaus unterstützen wir git-notes nativ. Artifacts ist von Grund auf agentenorientiert konzipiert, und Notes ermöglichen es Agenten, Git-Objekten Notizen (Metadaten) hinzuzufügen. Dazu gehören Prompts, die Zuordnung zu einem Agenten und weitere Metadaten, die direkt aus dem Repository gelesen oder in es geschrieben werden können, ohne die Objekte selbst zu verändern.

Die meisten Repositories sind nicht besonders groß, und Git ist auf äußerst effiziente Speicherung ausgelegt: Die meisten Repositories lassen sich in höchstens wenigen Sekunden klonen, wobei dies vor allem von Netzwerkaufbau, Authentifizierung und Prüfsummenberechnung bestimmt wird. In den meisten Agenten- oder Sandbox-Szenarien ist das praktikabel: Klonen Sie das Repository einfach beim Start der Sandbox und legen Sie los.

Aber was ist mit einem Repository im Multi-GB-Bereich und/oder Repositories mit Millionen von Objekten? Wie können wir ein solches Repository schnell klonen, ohne die Arbeitsfähigkeit des Agenten für Minuten zu blockieren und dabei unnötig Rechenleistung zu verbrauchen?

Ein beliebtes Web-Framework (mit 2,4 GB und einer langen Historie!) braucht fast 2 Minuten zum Klonen. Ein flacher Klon ist zwar schneller, aber nicht schnell genug, um auf eine einstellige Anzahl von Sekunden zu kommen, und wir möchten die Historie nicht immer weglassen (Agenten finden sie nützlich).

Können wir große Repos auf ~10-15 Sekunden reduzieren, damit unser Agent mit der Arbeit beginnen kann? Nun, ja: mit ein paar Tricks.

Im Rahmen der Einführung von Artifacts machen wir ArtifactFS als Open Source verfügbar, einen Dateisystemtreiber, der dafür entwickelt wurde, große Git-Repositories so schnell wie möglich einzubinden und Dateiinhalte bei Bedarf dynamisch nachzuladen, statt den Start durch den anfänglichen Klonvorgang zu blockieren. Das ist ideal für Agenten, Sandboxes, Container und andere Anwendungsfälle, bei denen die Startzeit entscheidend ist. Wenn Sie bei jedem großen Repository rund 90 bis 100 Sekunden Startzeit Ihrer Sandbox einsparen können und davon 10.000 Sandbox-Jobs pro Monat ausführen, dann entspricht das einer Ersparnis von 2.778 Sandbox-Stunden.

Sie können sich ArtifactFS als „Git-Klonen, aber asynchron“ vorstellen:

• ArtifactFS führt einen bloblosen Klon eines Git-Repositories aus: Es lädt den Dateibaum und die Refs, aber nicht die Dateiinhalte. Das kann bereits beim Start der Sandbox geschehen, sodass Ihr Agenten-Harness direkt mit der Arbeit beginnen kann.

• Im Hintergrund beginnt es, Dateiinhalte parallel über einen leichtgewichtigen Daemon herunterzuladen.

• Es priorisiert Dateien, mit denen Agenten typischerweise zuerst arbeiten möchten: Paketmanifeste (package.json, go.mod), Konfigurationsdateien und Code. Binäre Blobs wie Bilder, ausführbare Dateien und andere Nicht-Textdateien werden nach Möglichkeit nachrangig behandelt, sodass Agenten den Dateibaum bereits durchsuchen können, während die Dateien selbst nachgeladen werden.

• Wenn eine Datei noch nicht vollständig hydratisiert ist, wenn der Agent versucht, sie zu lesen, wird der Lesevorgang blockiert, bis sie vollständig geladen ist.

Das Dateisystem versucht nicht, Dateien zurück mit dem Remote-Repository zu „synchronisieren“: Bei Tausenden oder Millionen von Objekten ist das in der Regel sehr langsam, und da wir Git sprechen, ist es auch nicht nötig. Ihr Agent muss einfach committen und pushen, wie bei jedem anderen Repository. Es gibt keine neuen APIs zu lernen.

Wichtig ist außerdem: ArtifactFS funktioniert mit jedem Git-Remote, nicht nur mit unseren eigenen Artifacts. Wenn Sie große Repositories von GitHub, GitLab oder einer selbst gehosteten Git-Infrastruktur klonen, können Sie ArtifactFS weiterhin verwenden.

Unsere heutige Veröffentlichung ist nur die Beta-Version, und wir arbeiten bereits an einer Reihe von Funktionen, die in den nächsten Wochen veröffentlicht werden:

• Wir erweitern die verfügbaren Metriken, die wir bereitstellen. Aktuell liefern wir Metriken zu den wichtigsten Operationszahlen pro Namespace, Repository und zu den gespeicherten Bytes pro Repository, damit die Verwaltung von Millionen von Artifacts nicht zur mühsamen Pflichtaufgabe wird.

• Unterstützung für Eventabonnements bei Repository-Ereignissen, damit wir Ereignisse zu Pushes, Pulls, Klone und Forks für jedes Repository innerhalb eines Namespace ausgeben können. Dadurch können Sie diese Ereignisse auch konsumieren, Webhooks schreiben und sie nutzen, um Endnutzer zu benachrichtigen, Lifecycle-Ereignisse in Ihren Produkten zu steuern und/oder Post-Push-Jobs wie CI/CD auszuführen.

• Native Client-SDKs für TypeScript, Go und Python zur Interaktion mit der Artifacts-API

• Such-APIs auf Repository-Ebene und Namespace-weite Such-APIs, z. B. „Finde alle Repos mit einer package.json-Datei.“ 

Wir planen auch eine API für Workers Builds, mit der Sie CI/CD-Jobs für jeden agentengesteuerten Workflow ausführen können.

Wir stehen mit Artifacts noch am Anfang, möchten aber, dass unsere Preisgestaltung auch im Maßstab von Agenten funktioniert: Es muss kosteneffizient sein, Millionen von Repos zu haben, ungenutzte oder selten genutzte Repos sollten keine Belastung darstellen, und unsere Preise sollten der stark mandantengetrennten Natur von Agenten entsprechen.

Sie sollten sich außerdem keine Gedanken darüber machen müssen, ob ein Repository überhaupt genutzt wird oder nicht, ob es heiß oder kalt ist und/oder ob ein Agent es wieder aufwecken wird. Wir berechnen Ihnen den verbrauchten Speicher sowie die Operationen, die auf jedes Repository ausgeführt werden, etwa Klone, Forks, Pushes und Pulls.

Große, ausgelastete Repos kosten mehr als kleinere, weniger häufig genutzte Repos, und zwar unabhängig davon, ob Sie 1.000, 100.000 oder 10 Millionen davon haben.

Wir werden Artifacts auch im Laufe der Beta-Phase in den Workers Free-Tarif einbringen (mit einigen fairen Einschränkungen). Sollte sich diese Preisgestaltung ändern, werden wir während der gesamten Beta-Phase Updates bereitstellen, bevor wir die Nutzung in Rechnung stellen.

Artifacts startet in der privaten Beta, und wir erwarten, dass die öffentliche Beta Anfang Mai 2026 verfügbar sein wird. In den nächsten Wochen werden wir schrittweise weitere Kunden zulassen, und Sie können Ihr Interesse an der privaten Beta direkt bekunden.

In der Zwischenzeit können Sie mehr über Artifacts erfahren:

• Lesen Sie den Einstiegsleitfaden in der Dokumentation.

• Aufruf des Cloudflare-Dashboards (Erstellen > Speicher & Datenbanken > Artifacts)

• Lesen Sie die REST-API-Beispiele durch

• Mehr darüber erfahren, wie Artifacts unter der Haube funktioniert

Folgen Sie dem Changelog, um den Fortschritt der Beta zu verfolgen.