Artifacts: Versioned storage that speaks Git

Hello everybody and welcome to this today in Agents Week. I am here to talk about something that is very exciting that has been redacted in the past. We've been doing a lot of stuff about this, but with me, before we even get started, I want to talk to one of the blog authors of what we are looking at today, a thing called Artifacts. But first, a person who doesn't need any introduction at all, but I'm going to make him do it anyway. Matt Silverlock, can you introduce yourself? Of course. Thanks, Craig. I'm super excited, obviously, to talk through what's shipping today in Artifacts. I'm Matt Silverlock. I lead product for storage and databases and a bunch of other stuff at Cloudflare. I've been here many years. Yes, super excited to kind of talk about, whether you've read the blog or not, to talk about Artifacts and what it actually means and what it is. Yeah, totally. We've been pushing this for a while. We've been saying redacted for a while. I kind of like the social media buzz that's happened. It's nice to finally be able to talk about this without it being all blocked out. I was thinking, so we have the blog post, great blog post, read the blog post. You're not the only author. Let's give you a little shout out to start. Who are the other authors on this? It takes a village. So the authors are really only a slight reflection of everyone that's put the work in, but I spent a lot of time with Matt Carey and Dylan on our team, really working on the blog and working a lot on what Artifacts is today. But there's been a lot of people behind the scenes. But yeah, huge shout out to Matt and Dylan, who's been kind of grinding away, helping us get this over the line. Awesome. And I wanted to share, if this is okay, I'm going to share the new product page that just launched today. So this is super awesome. And I was thinking that we could kind of use this as a walk through this a little bit, Matt. I feel like I'm just now breathing in. It's been redacted to me. So I'm breathing this in. So I've got some questions about what's going on here. So let's just go from the top. Why are we building this? What is this gorgeous page talking about? The page is one thing. So I think it's probably no surprise to anyone as we have all of our coding agents, co-review agents, sandboxes, all of our harnesses. A lot of them rely on Git repos for actually managing and obviously committing the code and sharing it with others. Even just managing state before that sandbox shuts down. And I think the challenge is everything we built today for version control hasn't really scaled for agents. It was all built for humans. Every kind of social code network, GitHub or anybody else, kind of seeing this unprecedented scale. I think the CEO of GitHub posted that a week ago, actually, that they set a 14 times year over year increase in traffic volume, like Git operations, I think it was, on the network. And that's not like 14 from a base of a small startup that's been around a week. We're likely to scale up a few more VMs. This is like 14x from a company already operating at Internet scale. So I kind of wondered. Yeah, I think there's something we can go and solve here. If we do it differently for agents, it might actually work out. Why is it a hard thing for agents with Git? Like using Git just at the, if we're just using standard Git, what's the problem there? So, I mean, the good thing is actually sort of lesser problems. Agents are really good at Git. But we're running tens of agents, maybe in the background, right? We've got a bunch of open code or codex or code sessions, right? You've got a bunch of sub-agents, right? Maybe you actually want to commit more so that you can always roll back. So the agent's not like wallowing away a bunch of work. We've all seen the horror story of someone like burning, you know, a ton of tokens for an hour and beginning to commit, right? It's great if you can get away from that. But also kind of sucks if you go to commit and push and like, you know, the upstream is down and not available. We've all been seeing that as well. And so, again, we're just not ready for the volume that we have, but also maybe the volume we actually want is we want to commit more often, we want to push more often. How do you give every agent you have like an isolated repo that it can act on without crushing the other one that's a shared infrastructure at this kind of scale? Avoiding merge conflicts and all that, right? In many cases, you may not even want that social element, right? You may want to actually have the agent pull down an independent copy of that repo, say for code review, go and review that, right? Isolate it, act on that, right? In its own, right? And then maybe it posts some comments up to a centralized platform, right? Maybe your internal CI system, things like that, right? But if you can isolate its actions while it's actually working as much as possible, it ends up being really great, right? If you don't have to kind of have every agent clone your repo from GitHub or get blocked if things are down, that obviously makes your team more effective as well. That's awesome. So it's changing a little bit about thinking about how it works. What is it? Well, I guess I was just going to ask, what does it look like in code here? So should we walk this a little bit about what it feels like? Yeah. So we thought, again, you take away the human element, we're not building a social network for code. We're not thinking about call requests, right? Right. But agents, again, are really good at Git. So there's sort of three ways we think about this, right? There's the programmatic control point. How do I spin up 1, 10, millions of repos at scale, one for every agent on the fly as they need them or clone something from GitHub on the fly, right? So what we call artifacts, a few lines of code, like millions of repos, right? You can create that through workers. You can issue read tokens, write tokens. Hey, straight to my Git client, straight to my agent harness. Here's a regular Git remote. I just clone it. It works on it. It pushes from it, pulls from it. The agent doesn't have to know anything other than Git, which is huge because agents really do know Git. It's in the training sets, right? You're not teaching it a bunch of skills or hoping that it understands this magic new API, right? It just talks Git and your orchestration can take care of that. If you kind of look at the next example, well, yeah, there's still a bunch of stuff that you might want to pull down and seed your agents, but then have them work independently, right? Like, again, for code review or for snapshotting something or maybe a template, right? Oh, yeah, we can still pull something down and kind of clone from, say, GitHub. Like, say, you want to go and work on, like, the workers SDK, which is our regular tool chain, maybe working some stuff there, isolate and have your agent do a bunch of work that commits it and persists it, right? It's in a sandbox, so you don't want it on your local disk where it can get lost. You don't want to push it up to a pull request yet because you're not ready to do that, right? You want to work in isolation. Artifacts let you go and fork from something upstream as well or even clone itself and have, you know, 5,000 copies of the same repo inside Artifacts. And then with the last example, I was like, well, again... Sort of like a more disposable, right? It feels like... Yes, exactly. Yeah, yeah, yeah. And like, maybe it's disposable, maybe it's not, but you kind of get to make decision as you go. Yeah, yeah. Did it get it? Oh, it did. This isn't it. This isn't it. This isn't it. This one's it. Yeah, and you're... Yeah, exactly. Yeah, cool. Correct me if I'm wrong. We don't need to just run this in workers. Yes, exactly. Like, right, if you do, but you might run your control plane somewhere else, right? In another cloud, right? You might want to still orchestrate creating these repos using Artifacts before we've even used workers, right? We expose this over a regular HTTP API. We have language-specific SDKs, you know, TypeScript, Go, and Python. You obviously can co-generate these days, particularly in the world of agents, right? Language -specific SDK, if you have something in Rust or Alexia, or any other sort of language that your team might be using, right? And use that to manage Artifacts. Like, we want this to be a case where the control plane side can be operated from anywhere. And then the part that I'll sort of talk through now is also the actual Git side, right? Like, Git is a really, really powerful protocol for managing versioning. Like, again, why teach agents anything else if Git is right there? It's very, very good. They're very good at it. But it's also kind of nice if your environment, say, maybe you actually are in a worker, or maybe you're in Node.js, somewhere you can host Node.js or a Python application. What if you don't want to run a full Git or spawn out to Git in that process, right? It's kind of heavyweight. It doesn't really work in a lot of service environments in a way that you might expect. Well, with Artifacts, we also let you interoperate with it via language -specific SDKs and via those APIs, too. So you can commit files, you can clone those repos down inside that language and have that as, let's say, a JavaScript object for those files as well. And a lot of those sort of sandbox or lightweight use cases, say, like with dynamic workers, which we just shipped recently, right, to sort of have sort of lightweight workers that you sort of explore on the fly, they still might want some Git-like concepts where they're acting on files and committing files just without the full Git client embedded. And so we've sort of taken two approaches there. Super cool. Walk me through that real quick. We've got a lot of new concepts coming in. So walk me through a dynamic worker that has this Git or is making use of this Git. Walk me through that really quick, through this Artifacts. Yeah. Great question. So, you know, I've got an Artifacts namespace, right? I can create as many repositories inside it as I want. It could be thousands to millions or more. Say I'm spinning up a dynamic worker that I want to go and execute some code or tool as part of an agent harness. But I want to give it a place to maybe persist its output, persist some files, right? Maybe I want to take some files that it's already worked on in the past. And that dynamic worker and that Artifacts repository could potentially be tied to the same customer or agent, right? They have the same ID. I can address that however I want. When I spawn that dynamic worker, I can pass in a reference, as we call a binding, um, to that repository. And that dynamic worker can then act on just that repository on the fly. If it wasn't created before, I can create it at the same time to create dynamic worker. If I just need to persist those files and then pull them out, outside of the user code, then I have access to that in my control plane. And I've got, again, not just Git, but I've got this like versioned file system. I was talking to a friend who's a founder about this, and he's like, the Git stuff's really cool. But I actually have this use case where like my customers build workflows, and I have these config files and these workflow definitions, and they want to be able to roll back to them in different cases, right, for like part of their product surface. And it's like a versioned file system that I can go and do that with is really kind of powerful, right? And Git semantics just make it kind of easy to understand. Yeah, yeah, yeah. And for the humans as well. I think it's also, it's readable for us humans and also for the agents. I hadn't thought about that. I think that's neat. So like a dynamic worker could be versioned. You know, I've been playing build some stuff and like, I've been wanting to like find the right way to show code and then let them go and edit that. And so that's how to do that. I feel like, yeah, yeah. Iterate inside of a dynamic worker on building code. That's awesome. Super cool. Now, that totally landed for me. Thank you for that. Okay, so here's some use cases that we got. So agent workspaces, we've been talking about that one. Let's talk about config versioning here a little bit. Give me, give me, walk me one of those. Yeah. So just sort of partially touched on that, but I think we'll go a little bit deeper. Like, you know, if I'm talking about, you know, again, a startup that like wants to version like customer data, but like, again, there's a lot of cases like where if you think about Git, what's Git really good at? Git is really good at storing lots of objects, conversioning them and letting you version control, control those versions, but also like figure them out chronologically. You can roll back, you can revert, right? You can go and check out a previous commit. And so it kind of turns out to be particularly powerful if you have like, again, as part of your product surface, right? Maybe user -generated configuration, right? For their products or their product surface. You could spin up an artifacts repo for every user on your platform. They never have to know about the Git. You're not exposing them to Git, but you're using it to version the artifacts or the file or the objects that they're operating on. You can diff them like code if you want to can roll back, you can expose that rollback capability to users. And now you have this way for users to maybe even flip between versions of config and snapshot and make your platform a little bit more programmable. As a result, we've even been talking about ways we want to use this inside Cloudflare for where there's kind of Git semantics and the way artifacts work, which is distributed for some of this for our internal services, where it'd be great if I have this like Git-like place where I can roll back to a commit that's yesterday for non-working that is config. I'm not even thinking about Git. It's just, again, a really good way to express this kind of versioning system. Yeah, I think like we've all built those, right? We've all gone and built like a changelog sort of thing, right? And I guess it would totally make sense if it was in Git. That's awesome. You've got me going. My brain is going like crazy right now on what we could do. And then, of course, platform managed repos is the other one here. Oh, yeah, that's true, right? So you're going to go do your Terraform stuff. That's what we're talking about here, right? Yeah, exactly. Again, it could be notebooks, it could be infrastructure as code use cases, right? Content that's generated like web assets or JavaScript, CSS assets, right? It's like maybe like a web platform you're building, right? All of those things really work when they're on like version control. Again, Git's just a really expressive way to sort of solve that. But it's really nice. You don't have to run the Git infrastructure. You have the security. You don't have to scale it. You don't have to think about how you spawn them at runtime and clean them up, right? Or make them durable. I think, obviously, if a particular user or agent is dependent on a particular repo, well, you want that to be distributed. You want that to be highly available. If you're then having to replicate it and deal with all the storage constraints and do that, that is a lot of toil and work on your teams. Our job is to just make that work all the time. If you want to go and check that repo out, it should be available no matter where that agent's running in the world. Awesome. I love it. What are some of the unlocks that this gave you that you didn't see coming? Because I'm feeling it. You're telling me these unlocks and you're, oh, I didn't think about that. Yeah, so one thing we've been starting to use this for internally and just talked to a bunch of customers about is in our sandbox use case, right? And so we've got this internal sort of like what we call background agents inside Cloudflare that can be driven from chat and you can say, hey, go work on this ticket, right? Go and solve this problem. Go and grab these logs from our Elasticsearch stack and then go figure out, give me a first pass at a diagnosis on this problem that I'm trying to solve. Really, really powerful, right? Kind of these SRE type pieces sort of like ad hoc engineering tasks you can go solve. There's a lot of cases where I want to go and share a link to somebody else. I'm like, here's the session I was just running. I kind of got stuck or like, here's my thinking on this. Like, what is your thought? And yeah, I'll get to this point in a moment. You're like, okay, cool. Great. Like I've seen that before. How cool would it be if I could just from that link, go fork and get an isolated clone of that whole session and all the working files, right? All the files that it was working on, all of the potentially the config or the notes that it's taken or any other files that's pulled from other upstream repos at that exact point in time and go, hey, Ben, here's a version of this. Can you go like work on this instead of this like fork or this multiplier type environment? Turns out Artifacts is really, really powerful there because Artifacts can just clone its own repos. You can just call clone as many times as you want on any independent repo. You get a fully isolated copy. And now I will say, Ben can go and work on the thing that I was working on without touching or messing with my workspace, right? With his own set of privileges, he can go work on that and go, hey, actually, by the way, I was working on this over night or I was in a different time zone. And I think if I kind of crack this problem and like show me back the results, right? That's really, really powerful. So we can kind of separate this stuff out. And so it's not just about, like I said, not just about the Git part. That's just a really, really powerful primitive. And I think, you know, being able to speak Git is sort of the language of agents in many ways, but you end up being able to get like, if you can just arbitrarily copy these on the fly without having to like pull all the like bigger repo constraints or things like that, you can just fork, fork, fork, fork. And now I've got this kind of like multiplayer-like concept, right? And I think that comes back to how we built this out on DurableObjects, which has always sort of been inherently this sort of multiplayer concept of coordination. Right. And so that was my question. It's all DurableObjects all the way down. This is a DurableObject. It always is. Yeah. Yeah, it always is. Can you tell me a little bit more about the implementation details? So how do we make it work with Git? Let's get a little nerdy here. Yeah. So this is kind of actually how we kind of brought this together really, really fast. You know, we've got DurableObjects, our sort of, you know, best way to describe it is sort of like stateful workers or stateful serverless functions. We found that's the best way to resonate. It's not quite comparable to anything else, but they have an embedded SQLite database. They have state. They can spin up in any place in the world. It's in the name. They are durable, right? Like the storage is replicated under the hood. Great. Today they speak, you know, workers, they speak HTTP. You can speak RPC to them. Like Git's another protocol. It works over HTTP. The Git server is non-trivial, but we can also run WASN inside DurableObjects. And so the way this came together is that one of the folks on team Matt actually had a Zig implementation of a Git server. And we said, well, what if we ran that inside DurableObjects so that you get as much Git API coverage as possible? So again, so any Git client just works. You're not thinking about like, does this particular Git feature work? Does this other not work? Like we have almost complete coverage as much as possible, right? We use a Git client, real Git clients to test our API service, which is awesome too, so that it's fully end-to -end tested. But it's fundamentally like a Git server running inside a DurableObject. And every repo is represented by a DurableObject. The cool thing is Git's hyper-efficient in terms of storage. So even like some of the larger repos, like say like our own, like WorkerD or Workers SDK are sort of 200 to 500 megs. Something like Next.js is about two and a half gigs. So they fit really well within sort of like the 10 gigs sort of boundary of a Durable Object. Again, the cloning semantics is powerful. If you want to sort of clone them on the fly, that works really well with DurableObjects. And we've already kind of proven that this can scale to tens of millions to hundreds of millions of objects under the hood. And so we didn't have to go and rethink this whole architecture and this world of agents. We had this primitive that really, really works. And that's really efficient. There's a lot of optimization we need to do still on the Wasm layer and make that kind of work, right? We're launching in beta today, but we spent a lot of time kind of testing this instead of banging against it. It turns out this kind of primitive where how can I create this thing on the fly almost instantly and then address it from any part in the world? That could be a DurableObject, a multiplayer server, right? It could be a Git repository that any agent in my fleet can walk to and pull as it needs, or my 10 ,000 agents can go and have 10,000 repos on the fly, whichever way I want to sort of split that. And so it's really, really powerful for us of not having to worry about these infrastructure concerns, I think. My last thought there is really, all the parameters we've been building as sort of part of the development platform and part of workers, right? Let us go and do these things really, really quickly, which is great. We're not spending two years building the foundations and infrastructure to go and ship this. And we say, hey, actually, I think there's a problem we can go solve for customers. Nice. So awesome. And I think people are going to build on top of it as people do, right? When we give them the primitive, they start building on top of it. They figure out what the use case is even before we... Well, that's a great use case for it. So super excited. Yeah. I'd love to see someone build something in the social code sharing space or more in the multiplayer side, right? I think there's going to be tons of ideas that come out of this. And hopefully we've seeded a few of them in the docs and in the blog posts and in some of the examples we're working on. And we'll show some more of this stuff over the coming weeks as well. But I'm really, really excited to see what people build. Cool. Awesome. Same. Thanks so much for jumping on here and thanks everybody for watching from home. Any last things to drop here, Matt, before anything you want them to do? The people watching this? Yeah. Go read the blog if you haven't read the blog. That's probably the most important, blog.cloth.com. Today, it's one of the featured blogs. You can go to developer.cloth.com slash artifacts for the docs and just go get started. If you're wondering, how do I get started? Is there a wait list? No wait list. It's a public beta. You can go start today. You just need a workers' paid plan. That's the only restriction right now. And eventually it'll come to free as we work through the beta as well. Let's talk about workers' paid plan really quick. What does that mean? Workers' paid plan? Good question. $5 a month gives you access to workers, D1, durable objects, KV, pretty much everything on the workers' platform. Tons of included usage up front before you even start paying about that $5. And that does include artifacts as well. And so that's really the only area to get started. Again, not going to put you on a wait list to make you wait. Just want you to get started and start building. I know that people have been asking for this and trying to solve problems that this is probably going to solve for them. So I'm super excited and I'm so glad that it's out of redacted time and we can talk about it and we can start getting the conversation happening around this. Thanks everybody for hanging out during Agents Week. Again, more stuff about artifacts and all sorts of stuff that we announced today coming out real soon. So thanks for hanging out. Thank you Matt for being here with us and we'll see you next time.