Artifacts : une solution de stockage versionné qui parle le Git

Les agents ont changé la manière dont nous envisageons le contrôle des sources, les systèmes de fichiers et la persistance des états. Les développeurs et les agents génèrent plus de code que jamais (il devrait être écrit au cours des cinq prochaines années plus de code que dans toute l’histoire de la programmation), ce qui a entraîné un changement d’ordre de grandeur dans l’échelle des systèmes nécessaires pour répondre à cette demande. À cet égard, les plateformes de contrôle des sources connaissent des difficultés particulièrement graves : elles ont été conçues pour répondre aux besoins des humains, et pas à un volume multiplié par 10 et produit par des agents qui ne dorment jamais et peuvent, sans se fatiguer, travailler sur plusieurs sujets à la fois.

Nous pensons qu’il est nécessaire de disposer d’une nouvelle primitive : un système de fichiers distribué et versionné, conçu avant tout pour les agents, et capable de servir les types d’applications développés aujourd’hui.

C’est ce que nous appelons Artifacts : un système de fichiers versionné qui parle le Git. Vous pouvez créer par programmation des référentiels, en même temps que vos agents, sandbox, Workers ou tout autre paradigme de calcul, et vous y connecter depuis n’importe quel client Git standard.

Souhaitez-vous prévoir un référentiel pour chaque session d’agent ? Artifacts peut le faire. Chaque instance de sandbox ? Également Artifacts. Souhaitez-vous créer 10 000 reprises logicielles à partir d’un point de départ connu pour être fiable ? Vous l’avez deviné : toujours Artifacts. Artifacts expose une API REST et une API Workers native pour créer des référentiels, générer des identifiants et procéder à dse validations pour les environnements auxquels un client Git n’est pas adapté (c’est-à-dire dans n’importe quelle fonction serverless).

Artifacts est disponible en version bêta privée pour tous les développeurs ayant souscrit à l’offre Workers payante, et nous avons l’intention de le proposer en version bêta publique au début du mois de mai.

// 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

Et voilà ! Un simple référentiel, prêt à l’emploi, créé à la volée, avec lequel n’importe quel client Git peut interagir.

Et si vous voulez amorcer un référentiel Artifacts à partir d’un référentiel git existant afin que votre agent puisse y travailler de manière indépendante et effectuer des modifications indépendantes, vous pouvez le faire également avec .import():

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 })
  },
}

Consultez la documentation pour vous lancer, ou si vous souhaitez comprendre comment Artifacts est utilisé, comment il a été conçu et comment il fonctionne en coulisses : poursuivez la lecture.

Les agents connaissent Git. Il est profondément inscrit dans les données d’entraînement de la plupart des modèles. Le scénario idéal et les cas particuliers sont bien connus des agents, et les modèles optimisés en fonction du code (ou les harnais) sont particulièrement efficaces dans l’utilisation de Git.

Par ailleurs, le modèle de données de Git convient non seulement au contrôle des sources, mais aussi à toute situation pour laquelle vous vous avez besoin de suivre l’état, remonter dans le temps et conserver pendant longtemps de grandes quantités de petites données. Code, configuration, invites de session et historique de l’agent : tous ces éléments (les « objets ») que vous souhaitez souvent stocker sous forme de petits fragments (les « validations ») afin de pouvoir y revenir ou les rétablir (« historique »). 

Nous aurions pu inventer un protocole entièrement nouveau, sur mesure... mais se pose alors le problème du démarrage (bootstrap). Les modèles d’IA ne le connaissent pas, vous devez donc répartir les compétences, ou une interface de ligne de commande (CLI), ou encore espérer que les utilisateurs sont connectés à vos documents MCP... tout cela ajoute des contraintes. Et si nous pouvions nous contenter de fournir aux agents une URL Git distante HTTPS authentifiée et sécurisée, et les faire fonctionner comme s’il s’agissait d’un référentiel Git ? Il s’avère que la solution fonctionne plutôt bien. Et pour les clients ne parlant pas le Git — tels qu’un Cloudflare Worker, une fonction Lambda ou une application Node.js — nous proposons une API REST et (bientôt) des SDK spécifiques à chaque langage. Ces clients peuvent également utiliser isomorphic-git, mais dans de nombreux cas, une API TypeScript plus simple peut réduire la surface d’API nécessaire.

Vous pourriez avoir l’impression que l’API Git d’Artifacts ne sert qu’au contrôle de version, mais il s’avère que l’API Git et le modèle de données constituent un moyen puissant de conserver un état persistant, d’une manière qui vous permette de procéder à des reprises logicielles, de remonter dans le temps et de différencier les états pour n’importe quelle donnée.

Au sein de Cloudflare, nous utilisons la solution Artifacts pour nos agents internes : en maintenant automatiquement l’état actuel du système de fichiers et l’historique de session au sein d’un référentiel Artifacts par session. Cela nous permet de :

• Consolider l’état de la sandbox sans avoir à provisionner (et conserver) le stockage par blocs.

• Partager les sessions avec d’autres utilisateurs et leur permettre de remonter dans le temps à la fois dans l’état de la session (invite) et dans l’état du fichier, indépendamment du fait que des validations aient été effectuées dans le référentiel « réel » (contrôle de la source).

• Et le meilleur pour la fin : dupliquer une session à partir de n’importe quel point, et laisser notre équipe partager des sessions avec un collègue et lui permettre de la reprendre. Vous déboguez quelque chose et vous voulez un autre avis ? Envoyer une URL et la dupliquer. Vous voulez améliorer une API ? Demandez à un collègue de la dupliquer et de reprendre là où vous vous êtes arrêté.

Nous avons également parlé à des équipes qui souhaitent utiliser Artifacts dans des cas où le protocole Git n’est pas du tout obligatoire, mais où la sémantique (restauration, clonage, comparaison des différences) l’est. Vous stockez les configurations personnalisées par client dans le cadre de votre produit et vous souhaitez bénéficier de la possibilité de les restaurer ? Les artefacts peuvent en être une bonne représentation.

Nous sommes impatients de voir les équipes explorer les scénarios d’utilisation hors Git autour d’Artifacts, autant que ceux liés à Git.

Artifacts est construit à partir de Durable Objects. La capacité de créer des millions (ou des dizaines de millions) d’instances de calcul isolé et avec état est inhérente au fonctionnement actuel de Durable Objects ; c’est exactement ce dont nous avions besoin pour prendre en charge des millions de référentiels Git par espace de noms.

La Major League Baseball (pour la diffusion en direct des matchs), les tableaux blancs de Confluence et notre propre SDK Agents utilisent des Durable Objects en coulisses à une échelle significative ; nous développons donc cette solution sur une primitive que nous avons en production depuis un certain temps.

Ce dont nous avions besoin, toutefois, était une mise en œuvre de Git pouvant être exécutée sur Cloudflare Workers. Elle devait être petite, aussi complète que possible, extensible (notes, LFS) et efficace. Nous en avons donc créé une dans Zig, et nous l’avons compilée dans Wasm.

Pourquoi avons-nous utilisé Zig ? Trois raisons :

1.  L’ensemble du moteur de protocoles git est écrit en Zig pur (pas de libc), compilé dans un fichier binaire WASM d’environ 100 Ko (avec de l’espace pour l’optimisation !). Il met en œuvre SHA-1, la compression/décompression zlib, l’encodage/décodage delta, l’analyse des paquets et le protocole git smart HTTP complet, le tout, de A à Z, sans aucune dépendance externe autre que la bibliothèque standard.

2.  Zig nous permet de contrôler manuellement l’allocation de mémoire, ce qui est important dans les environnements limités tels que Durable Objects. Le système de génération Zig nous permet de partager facilement du code entre le runtime de WASM (WebAssembly) (production) et les versions natives (tests avec libgit2 pour vérification de l’exactitude).

3. Le module WASM communique avec l’hôte JS par l’intermédiaire d’une interface légère de rappel : 11 fonctions importées par l’hôte pour les opérations de stockage (host_get_object, host_put_object, etc.) et une pour la diffusion en sortie (host_emit_bytes). Le côté WASM peut être entièrement testé en environnement isolé.

En arrière-plan, Artifacts utilise également R2 (pour les instantanés) et KV (pour le suivi des jetons d’authentification) :

^{Fonctionnement d’Artifacts (Workers, Durable Objects et WebAssembly)}

Un Worker agit comme le front-end, gérant l’authentification et l’autorisation, les indicateurs clés (erreurs, latence) et recherchant chaque référentiel Artifacts (Durable Object) à la volée. 

Ces initiatives comprennent plus spécifiquement les mesures suivantes :

• Les fichiers sont stockés dans la base de données SQLite de l’Objet durable sous-jacent.

  • Le stockage Durable Object ne peut pas dépasser 2 Mo de lignes : les objets Git volumineux sont donc fragmentés et stockés sur plusieurs lignes.

  • Nous utilisons l’API sync KV (state.storage.kv)  qui dans son fonctionnement interne repose sur SQLite.

•  Les DO (Durable Objects) ont des limites de mémoire d’environ 128 Mo : cela signifie que nous pouvons en générer des dizaines de millions (ils sont rapides et légers), mais nous devons respecter ces limites.

  • Nous utilisons intensivement la diffusion en continu pour les chemins de récupération et d’envoi, et renvoyons directement un `ReadableStream<Uint8Array>` construit à partir des fragments de sortie WASM bruts.

  • Nous évitons de calculer nos propres deltas git ; au lieu de cela, les deltas bruts et les hachages de base sont conservés parallèlement à l’objet résolu. Lors d’une récupération, si le client demandeur possède déjà l’objet de base, Zig émet le delta au lieu de l’objet complet, ce qui permet d’économiser de la bande passante et de la mémoire.

• Prise en charge de la version v1 et v2 du protocole Git.

  • Nous prenons en charge des fonctionnalités telles que ls-refs, des clones peu profonds (deepen, deepen-since, deepen-relative) et la récupération incrémentielle avec négociation have/want.

  • Nous disposons d’une suite de tests complète, avec des tests de conformité sur des clients git et des tests de vérification sur un serveur libgit2 conçu pour valider la prise en charge des protocoles.

Par ailleurs, nous proposons la prise en charge native des notes git. La solution Artifacts est conçue pour être orientée agent, et les notes permettent aux agents d’ajouter des notes (métadonnées) aux objets Git. Cela comprend les invites, l’attribution d’agent et d’autres métadonnées qui peuvent être lues/écrites depuis le référentiel sans muter les objets eux-mêmes.

La plupart des référentiels ne sont pas très volumineux et Git est conçu pour être extrêmement efficace en matière de stockage : la plupart des référentiels sont clonés en quelques secondes seulement, au maximum, et ce phénomène est dominé par le temps de configuration du réseau, l’authentification et le calcul de la somme de contrôle. Dans la plupart des scénarios d’agent ou de sandbox, c’est possible : il suffit de cloner le référentiel au démarrage de la sandbox et de commencer à travailler.

Mais qu’en est-il d’un référentiel de plusieurs Go ou d’un référentiel contenant des millions d’objets ? Comment cloner rapidement ce référentiel, sans bloquer la capacité de l’agent à travailler pendant quelques minutes et à consommer beaucoup de puissance de calcul ?

Le clone d’un framework web populaire (à un volume de 2,4 Go et avec un long historique !) prend près de 2 minutes. Un clone peu profond est plus rapide, mais pas suffisant pour atteindre un chiffre de quelques secondes, et nous ne voulons pas toujours ignorer l’historique (les agents trouvent cela utile).

Pouvons-nous réduire les référentiels volumineux à environ 10 à 15 secondes pour que notre agent puisse se mettre au travail ? Eh bien, oui : en suivant quelques conseils !

Dans le cadre du lancement d’Artifacts, nous proposons ArtifactFS en open source, un pilote de système de fichiers conçu pour monter des référentiels Git volumineux aussi rapidement que possible, en chargeant le contenu des fichiers à la volée, au lieu de bloquer lors du clone initial. Il est idéal pour les agents, les sandbox, les conteneurs et les autres scénarios d’utilisation dans lesquels le temps de démarrage est très important. Si vous pouvez réduire d’environ 90 à 100 secondes le temps de démarrage de votre sandbox pour chaque grand dépôt, et que vous exécutez 10 000 de ces tâches par mois : cela représente 2 778 heures de sandbox économisées.

Vous pouvez envisager ArtifactFS comme un « clone Git, mais asynchrone » :

• ArtifactFS exécute un clone sans blobs d’un référentiel Git : il récupère l’arborescence de fichiers et les références, mais pas le contenu des fichiers. Il peut accomplir cette tâche lors du démarrage de la sandbox, ce qui permet ensuite à votre harnais d’agent de se mettre au travail.

• En arrière-plan, il commence à hydrater (télécharger) le contenu des fichiers simultanément par l’intermédiaire d’un démon léger.

• Il donne la priorité aux fichiers sur lesquels les agents veulent généralement travailler en premier : les manifestes de packages (package.json, go.mod), les fichiers de configuration et le code, en dépriorisant les blobs binaires (images, exécutables et autres fichiers non texte) chaque fois que possible, afin que les agents puissent parcourir l’arborescence de fichiers pendant que les fichiers eux-mêmes sont hydratés.

• Si un fichier n’est pas complètement hydraté lorsque l’agent essaie de le lire, la lecture sera bloquée jusqu’à ce qu’il soit hydraté.

Le système de fichiers ne tente pas de « synchroniser » les fichiers avec le référentiel distant : avec des milliers ou des millions d’objets, l’opération est généralement très lente, et comme il s’agit de Git, nous n’avons pas besoin de le faire. Votre agent a simplement besoin de valider et envoyer (push), comme il le ferait avec n’importe quel référentiel. Aucune nouvelle API à apprendre.

Qui plus est, ArtifactFS fonctionne avec n’importe quel Git distant, pas seulement avec nos propres Artifacts. Si vous clonez des référentiels volumineux issus de GitHub, de GitLab ou d’une infrastructure Git auto-hébergée, vous pouvez toujours utiliser ArtifactFS.

Le lancement d’aujourd’hui ne concerne qu’une version bêta, et nous travaillons déjà sur un certain nombre de fonctionnalités que vous découvrirez au cours des prochaines semaines :

• Élargissement des indicateurs disponibles que nous exposons. Aujourd’hui, nous fournissons des mesures correspondant au nombre d’opérations clés par espace de noms, référentiel et octets stockés par référentiel, de sorte que la gestion de millions d’Artifacts n’est pas fastidieuse.

• Prise en charge des abonnements aux événements pour les événements au niveau du référentiel, afin de nous permettre d’émettre des événements sur les envois, extractions, clones et reprises logicielles vers n’importe quel référentiel au sein d’un espace de noms. Ce mode de fonctionnement vous permettra également de consommer des événements, d’écrire des webhooks et d’utiliser ces événements pour notifier les utilisateurs finaux, gérer les événements de cycle de vie au sein de vos produits ou exécuter des tâches de post-envoi (comme l’intégration continue/la livraison continue (CI/CD).

• SDK clients natifs TypeScript, Go et Python pour interagir avec l’API Artifacts

• API de recherche au niveau du référentiel et à l’échelle de l’espace de noms, par exemple « chercher tous les référentiels associés à un fichier package.json ». 

Nous prévoyons également une API pour Workers Builds, qui vous permettra d’exécuter des tâches d’intégration continue/de livraison continue (CI/CD) sur n’importe quel flux de travail piloté par un agent.

Nous n’en sommes encore qu’aux débuts avec Artifacts, mais nous souhaitons que notre tarification soit efficace à l’échelle agentique : elle doit être rentable pour des millions de référentiels, les référentiels inutilisés (ou rarement utilisés) ne doivent pas constituer un frein, et notre tarification doit correspondre à la nature massivement mono-locataire des agents.

Vous ne devriez pas non plus avoir à vous demander si un référentiel va être utilisé ou non, s’il fait chaud ou froid ou si un agent va le réveiller. Nous vous facturerons le stockage que vous consommez et les opérations (p. ex. clonages, envois, reprises logicielles et extractions) pour chaque dépôt.

Les référentiels volumineux et très fréquentés coûteront plus cher que les référentiels plus petits et moins souvent utilisés, que vous en ayez 1 000, 100 000 ou 10 millions.

Nous ajouterons également Artifacts à l’offre gratuite Workers (dans certaines limites équitables) au fur et à mesure de la progression de la version bêta, et nous fournirons des mises à jour tout au long de la version bêta en cas de modification de la tarification et avant la facturation de toute utilisation.

Artifacts est lancé en version bêta privée, et nous prévoyons une version bêta publique pour le début du mois de mai (2026, pour être précis !). Nous allons intégrer les clients progressivement au cours des prochaines semaines, et vous pouvez manifester directement votre intérêt pour la bêta privée.

En attendant, vous pouvez en apprendre davantage sur « Artifacts » en :

• Lisant le guide de démarrage dans les docs.

• Accédant au tableau de bord de Cloudflare (Build > Storage & Databases > Artifacts)

• Consultant les exemples de l’API REST

• En savoir plus sur le fonctionnement d’Artifacts dans les coulisses

Suivez le journal des modifications pour suivre la version bêta dans sa progression.