Arrakis: How To Build An AI Sandbox From Scratch - Abhishek Bhardwaj, OpenAI

Hello everyone, my name is Abhishek. I'm the solo founder and developer of Arrakis, an open-source code execution and computer-use sandboxing service for AI agents. Today we'll chat about why sandboxing is the next big unlock in intelligence, and what goes into building an AI sandbox like Arrakis.

A little bit about my background: I went to school at Carnegie Mellon, where I studied distributed systems and operating systems. At Microsoft, I worked on Windows Subsystem for Linux and a Smartwatch OS from scratch. At Google, I worked on cutting-edge systems using containers and inventing something called MicroVMs, which we'll discuss in plenty detail today.

The last couple of years I was at Replit, working on infra and RAG-based code chat, before I founded Arrakis,right at the intersection of my background in operating systems, sandboxes, and AI agents.

So why do we need AI sandboxes? For one, the latest models like O3 all leverage tool calling, such as search or code exec during inference, to give smarter replies to user queries. These tool calls require AI sandboxes for execution.

For reinforcement learning as well, during the training phase you need sandboxes to run reward functions at scale. Agents can also go a long way with a full Linux sandbox at their disposal. For example, during code generation they can debug entire apps by using Linux commands like ps ls of to see if the code is running and debugging it.

They can backtrack, re-plan, and work toward the goal again with a sandbox at their disposal. Security is paramount; agent code is no different than you using any code from GitHub or Stack Overflow and running it on your host or production server.

This code could be buggy or malicious and can get rooted, and can access your data or your client's data, so we need some amount of locking down in this sandbox.

Let's see a sandbox around us. I know we've seen Canvas by OpenAI, Claude artifacts. This is Manus AI; it uses a sandbox very heavily. You can see that I've asked it to create a ChatGPT clone, and it's running all sorts of commands inside the Linux sandbox.

It will also try to run the app, see if it didn't work, and then try to fix it itself. You don't need a big prompt or a lot of alignment and frameworks to make a coding agent when it has a Linux sandbox at its disposal.

Just because it has all of this Linux knowledge in its pre-training data, so it could go a long way for code generation tasks inside the sandbox.

With that background, introducing Arrakis. Arrakis provides a secure, fully customizable, and self-hosted solution to spawn and manage AI sandboxes for code execution and computer use. It has out-of-the-box support for backtracking via snapshot and restore. And what that means is agents can backtrack and don't have to start from scratch if they fail during multi-step workflows.

Best of all, it is completely open source and you can dive into the code, and we will do that today to see how to make an AI sandbox like Arrakis from scratch.

Now, let's go over the features of Arrakis. Let's start with MicroVM-based secure code execution. As discussed, security is paramount for AI sandboxes. Arrakis uses MicroVMs as a runtime, and we'll go into more detail there. But like I mentioned, code generated by AI agents would increase exponentially as people are using Windsurf, Cursor, and more and more coding agents.

We don't want these malicious or potentially buggy code to get rooted, and we want to protect your data, your systems, your client's data. Second is speed. Speed is paramount for AI sandboxes. You want these things at scale to be able to call tools and generate code fast.

Currently, Arrakis boots in less than 7 seconds, which is way, way better than 40 seconds for a traditional old VM on macOS. We have a PR outright now to get that time below a second. Also, snapshots are super fast, single-digit seconds, and just getting lower and lower with work.

Arrakis handles all sorts of port forwarding for you, so code exec, browser use, you can access them easily via just a public URL and a port. You don't have to muck with IP tables, firewalls; Arrakis takes care of all of that.

Easy computer-use agents, a lot of workflows. Chrome is pre-installed, and there's a VNC server that's hooked up pre-installed, and so you can access the GUI of your browser very easily. You can see a Chrome instance open in an Arrakis sandbox here.

Backtracking is super important as well. Like I mentioned, Arrakis supports snapshot and restore, so agents can checkpoint progress by snapshotting the sandbox. If they fail in their multi-step flows, they can restore an old snapshot. This way we can get more reliable, higher-order, complex task execution via agents.

Arrakis has a dead simple and ubiquitous API. It has a Python API, a Golang client, and MCP server. It has an OpenAPI-compatible YAML file, so you can generate any client in any language that you want.

Lastly, it's configurable with Docker tooling, so you can use your existing Docker commands, and there's a Docker file to customize what binaries and packages are installed in the sandbox. So Arrakis gives you complete control and freedom on what you want to run inside your sandbox.

So this is the high-level architecture of Arrakis. You can see it has a REST server that spawns and manages MicroVM sandboxes. Each of the sandboxes runs a VNC server and a code server. We do the port forwarding to expose a VNC server, and you can access the GUI and Chrome via a VNC client.

We give an Arrakis CLI, Golang-based CLI, called Arrakis client. There's a Python SDK. There's also an MCP server that's not shown here. So there's a lot going on here, but in the next half of the presentation we'll work toward what all goes inside each of these components and see how an AI sandbox is made.

Arrakis is tied to Linux just because the MicroVM tech that we used is tied to dev-kvm, which is the Linux virtualization device. So it's tied to the Linux virtualization stack.

Let's move to the API of Arrakis, and you can see we have a very simple REST-based API. There's a key VMs resource that you use to start, stop, delete a VM. Inside that, you also have a snapshots resource, so you can snapshot a VM very easily by the snapshots API.

And within a VM, you get command execution with the command resource, and you can upload and download files from within the sandbox using the files API. And finally, there's a health check endpoint as well if you want to have a distributed version and you want to see the health of your Arrakis REST server.

This is what the API exposes. Okay, we discussed about the API that Arrakis exposes, and now we have an updated architecture. We can see that we have a REST server running on a Linux host or a Linux server exposing a REST API via the Python SDK or the Golang CLI.

We also have an MCP server and an OpenAPI-based YAML file that you can use to generate clients in any languages. And we'll keep updating this architecture as we go inside the architecture of the sandbox. So let's move forward.

Arrakis uses something called MicroVMs to give secure sandboxes to models and AI agents. But what are MicroVMs, and why do they, or how do they provide a secure environment? For that, let's take a quick tour of Linux sandboxing, and I'll build from scratch your knowledge about Linux sandboxing and what our different options are and why we chose MicroVMs.

Let's start with the Linux execution model. So this diagram kind of goes over the basic Linux execution model. A thread is the smallest unit of execution on Linux. Each thread has a task struck in the kernel that's in the scheduler run queue.

And what that means is there's a linked list or a data structure connecting these task structs, and these are used to represent each thread or the unit of execution. A process is a logical construct made up of multiple threads.

Threads in a process have different pids, but the same pid, they share page table and other resources, and so they are logically bound and connected by shared resources. Kernel provides privileged access to hardware. If this wasn't the case, then any buggy or malicious code running in a thread can just crash an entire device or do malicious things.

And special instructions are needed to switch to kernel mode or supervisor mode, and we need to invoke a system call for privileged access. And so you can see in the diagram when we do int ox80, that's us trying to get to privileged mode and get access to hardware or do privileged operations on our OS.

Okay, we've discussed the basic Linux thread-based execution model. Now let's discuss about containers. Why do we have them, and what they are? So first, let me give you a programmer's perspective of what problem containers solve. And so in this diagram you can see a container and the concept of namespaces.

But yeah, let's dive deeper. So first, why? Let's say my app needs Python 3.8, a version of a library, foo, with 1.2, and my server has Python 3.9, 3.6, 3.12, but doesn't have 3.8, and it doesn't even have the library, foo.

So how do I run my app on an arbitrary server without these things? And so containers, from a programmer's perspective, are a way to package an app's dependencies along with the core business logic. As a corollary, they let you run arbitrary user code on your machine, which, as we've discussed, is one of the core features required by an AI sandbox.

Getting more technical, on a Linux, a container is a collection of namespaces of different resources. So process, mount, and net, for our example of key resources that you can abstract in namespaces. What that means is, if you have a process namespace, for instance, in a container, it sees certain processes as pid 1, pid 2, and pid 3 within its namespace.

But outside, these are arbitrary processes running in the user space, in the root namespace. So container has a very abstracted or bound view of its own resources, and the host can peek inside a child container namespace, but a container cannot look upwards and see in its host namespace.

So this is one way of

telling processes or contents running in the container that you have your own controllable resources, and it's like a little bit of a false boundary, so to speak. So like I said, yeah, outside the container you can see everything inside your child's namespace, but it doesn't work the opposite way.

We also use something called cgroups in tandem with namespaces. So containers are collections of namespaces, and cgroups can control how many resources a container can access. So what percentage of memory, what percentage of CPU do you want to give to a specific container running on your machine?

Let's talk about the security story of containers.

And so here you can see a container consisting of a pid namespace running on top of a kernel on a server. And so you can see that after all, containers run as native processes on top of the kernel.

There's a logical binding of resources, but at the end, these are just processes running on top of the kernel. So you can imagine now that if you have a kernel vulnerability, any malicious or buggy process can attack the kernel and gain root.

And then once it becomes root, it can do basically anything it wants. It can dump memory, it can read your data, it can pretend to be someone it's not. So all sorts of attack vectors are on the cards.

Okay, so we now know what containers are and what's one of the security flaws that containers have. So what are the alternatives? How can we, let's say, sandbox or jail container to kind of mitigate these things? So let's look into that.

Right, and so like I said, if there's a kernel vulnerability, a container can attack it and get rooted. But let's see how we can reduce the attack surface by using some techniques that we have. So one is, the fundamental principle is to jail the containers by restricting the Linux capabilities and the syscalls they can call.

And so, in effect, reducing the attack surface that's available to it. And so the way this works is,right, Linux has a concept of caps or capabilities, and that kind of govern what syscalls or privileged operations a process can do.

And so you only give capabilities that are required by your container to do its work. You don't give it a catch-all. And these indirectly control what system calls and what code paths they can take within the system call.

Another thing is seccomp, which filters the arguments you can give to a system call or just block system calls altogether. So seccomp filters is another option. And so these are gnarly or hard-to-use APIs with a lot of granular error checking.

So there's a library called minijail that we used to use at ChromeOS that I highly recommend to check out. That helps in jailing and sandboxing of containers and processes. Okay, sandboxing can only go so far, and jails also have their limits.

This can still bypass them. Let's say you need a heavier hammer,right? What options do we have? So let's discuss going from containers to virtualization on Linux. So let's discuss a high-level view of virtualization. Virtualization provides another primitive to run untrusted or arbitrary code on your machines.

Each VM has its own guest user space and guest kernel. And so unlike the container model where the processes run directly on top of the host kernel, in this way the processes have their own isolated kernel and user space, and there's a smaller attack surface to get to the host kernel compared to a container.

And so the question is, in this diagram, you need to access hardware and other resources. So how do VMs then access the host resources in this virtualization model on Linux? Okay, now let's dive deeper into Linux virtualization.

Yeah, as you can see, this is a more fleshed-out diagram of Linux virtualization. Let me go over the main parts here. So on theright-hand side, there's some client that wants to spawn a virtual machine. And the main actor here is this process called the VMM, the Virtual Machine Monitor.

And you might have heard of QEMU, CrossVM, or FileCracker. The main process here is the VMM. The VMM sits on top of dev-kvm, which is like a device in the Linux kernel that exposes the processor's virtualization stack and provides a nice API for the VMM process to talk to in order to start a VM and give it access to privileged resources.

So let's discuss how this works. The VMM talks to the KVM device to spawn VMs, and it also manages emulated devices inside. So you can see there's a block device and there's a net device. Some VMMs spawn these in other sandbox processes, and some VMMs have them in the same process.

To the client process, it looks like the VMM thread is blocked, but really, inside that thread, we are running all the guest code on the hardware. So in a separate virtualization context on your processor, this hardware code is running.

Whenever the virtual machine needs to access disk or net or any other privileged resource on the host, it returns back to the host. So the VMM process gets a VM exit, and then it figures out why the exit happened, like which device caused the exit: block, net, or something else.

It then talks to the host kernel to talk to the block disk device or the net device, gets a response, and sends it back to the guest with a VM resume. So the whole idea is that VM exits and resumes are very, very performance-affecting, and so you want to minimize this and want to keep the guest code running in the guest context as much as possible.

So if you're CPU-bound inside the guest, you're technically paying no penalty in a hardware virtualization model because you're running directly on the processor. But if you need a lot of disk and net and other device access, then there are other ways to think about performance because you might be exiting too often, and there are other things you can do.

You can cache more state in the guest memory and things. But yeah, containers run directly on top of your host OS, so performance isn't a big factor because they're native processes. But the trade-off is of security. Here, you get better security, but in some loads, the trade-off might be in performance.

Okay, we've now discussed Linux virtualization and how it works. So what are MicroVMs, and how do they differ from traditional VMs? So let's take a look.

Okay, and so as you can see, MicroVMs are slightly different from traditional VMs. So first of all, this term came from the CrossVM project at ChromeOS. CrossVM was the first Rust-based Virtual Machine Monitor. And the reason we rewrote QEMU, like VMMs, into Rust is they provide a memory-safe implementation of virtualization.

And so one aspect is that technically untrusted code running in a guest can attack your host by attacking the devices written in C, which have memory safety-related bugs. So writing Rust gives you some degree of sanity there. Separately, another feature of these VMMs is they jail their emulated devices separately.

So you can jail the block device to only have block-related system calls. So if you compromise block, you don't access network-related things. And vice versa, you jail the net device to just have network-related system calls. So yeah, one way MicroVMs are different is they're written in Rust, and they have this more jailing-based architecture for their emulated devices.

And so one aspect is security. The other aspect is why are they called MicroVMs? Where does the micro come from? And they're known to boot really fast. So why and how do they boot fast and also take less memory?

So old VMMs like QEMU support a lot of architectures and have many, many emulated devices supported. MicroVMs like CrossVM, FileCracker, Cloud Hypervisor don't do that. They only support one or two architectures, Intel and ARM, and have support for the major devices and not any obscure device as well.

What this means is that there's less code, less code paths at boot, and so they just boot up blazing fast, and at runtime, take less memory. And so the MicroVM, the micro is actually a reflection of the VMM process, either CrossVM or FileCracker, versus what's running inside the guest.

And so you can think of MicroVM as this new security-first way of running virtual machines that are lighter weight, boot fast, and consume less memory.

Okay, hopefully that background was useful on the different ways of sandboxing untrusted code on Linux. So with that, Arrakis chooses a MicroVM runtime as the final execution environment for these AI sandboxes. And so security is one of the key design choices of Arrakis because it's written with coding agents in mind.

And coding agents might have multi-tenant or different clients running on the same server with LLM-generated code accessing different clients' data. So we don't want one piece of untrusted code getting rooted on your server and accessing some other client's data.

And so multi-tenant code execution is untrusted code execution is a very, very key use case and design factor behind choosing MicroVMs. They also provide fast boot times, as we discussed. Snapshotting is super important for Arrakis, and MicroVMs provide a way to fast snapshot by just dumping the entire guest memory.

This isn't as easy to do with containers and even with gvisor that we'll discuss. And with MicroVMs, you can just allocate some virtual memory and then just dump it when you want to snapshot and restore it when you want to restore the VM.

And so I wanted to discuss different VMMs that we have the option of choosing. So like I said, CrossVM started the whole MicroVM revolution, and with that came a bunch of other Rust-based VMMs. So FileCracker and Cloud Hypervisor are two VMMs forked from CrossVM.

If you go over the codebase, you'll see many remnants of CrossVM in both. FileCracker is the underpinning behind AWS Lambda. It's used for serverless loads, and it has a more fleshed-out REST API, I would say, and it also has a better jailing architecture.

Cloud Hypervisor is a more general-purpose enterprise VMM. When I chose it, it had hot plugging of devices, which means you could add and remove RAM very easily as a PCI device when you're running a sandbox. It had GPU support, and it had snapshot support at the time.

And from a software project point of view, it isn't controlled by one specific company. There are different companies there. So it made a lot of sense to use Cloud Hypervisor as the MicroVM VMM for Arrakis. Another option we didn't discuss separate from MicroVMs is gvisor, which I would say is closer to a container in performance but slightly better in security.

Still, you can attack the host kernel with untrusted code running in gvisor, but based on your needs and security guarantees, it's a good in-between option. You do get GPU access more easily in gvisor and containers versus MicroVMs. So if that's a factor, then you can choose one of those and decide what your security guarantees are.

Okay, so now we've discussed why we chose Cloud Hypervisor and MicroVMs as the runtime for AI sandboxes in Arrakis. Let's move forward.

Okay, so now we can see that there's the updated architecture from the one we started off before. So earlier we had just an API. Now we can see that the REST server is managing these MicroVM-based sandboxes. The dotted process is actually the Cloud Hypervisor VMM process.

It runs the guest code in a thread in a virtual context, and it's talking to dev-kvm to run these MicroVM virtual machines. Okay, so let's move forward. Okay, now let's discuss the storage of the file system within each sandbox.

After all, it might need to create files, read from them, and write to them. And so one attack vector we haven't considered is untrusted, malicious, or buggy code that can actually delete files inside your sandbox. And it could delete very important files on your file system and could make the sandbox non-functional, basically.

And so we need to kind of protect the root FS running inside the sandbox. So we have a shared base layer of a RO root FS that's shared between sandboxes. And you can see that this is the yellow one with user bin A here.

But on top of that, every sandbox gets its own read-write layer. So this is where all the new files it creates go. And so you have this very nice balance between the root FS being protected and shared between sandboxes, but they get their own read-write layer.

And when we snapshot a sandbox, we also persist or back up just the read-write layer. We don't need to persist the read-all layer. So we have this nice sharing and per-sandbox semantics here.

Okay, and now let's go to the code and actually see how this happens,right? So the sandbox, when it boots up, already has this set up. All it sees is a root mount path. And just like any other Linux system, there's no difference.

But we do all the magic before the sandbox, as soon as the sandbox boots, and we start the first PID1 inside the sandbox. And so you can see here, this is the init.sets script running inside the guest, which is our sandbox, and it's setting up this overlay FS here.

And as soon as it does that, we start the booting process and boot to PID1. And every process within our sandbox just sees a regular file system, but we've done the magic underneath.

Yeah, and with that, let's see our updated architecture. So we had the REST server, we have these MicroVM sandboxes, and now we see every disk device is mounted on top of this overlay FS, and each sandbox gets its own read-write layer.

Okay, with that, let's move on to networking.

Okay, every sandbox needs to have networking. It might need to do other actions or call other tools or APIs. And so we need to provide each sandbox with a network. And so each sandbox in Arrakis runs in a virtual machine, like we discussed, with its own isolated networking.

The networking setup consists of a tap device. So it's like a virtual networking interface on Linux. Each sandbox gets a unique tap network device. So when we spawn the MicroVM sandbox, we're creating this tap device for it. And we have a Linux bridge on the host, which is the Linux server, where all the tap devices are connected to the Linux bridge on the host.

And the last part is we take care of port forwarding. So Arrakis forwards ports from your host into the code server or the VNC server. So you don't have to worry about how to access these things on your sandbox.

Okay, let's go over some code to set up networking here. So this is a function from Arrakis. It sets up the bridge device, and it also sets up the firewall rules to forward data back and forth from the host to the sandbox and the sandbox to the host.

And so you can see that here we come in and we create a bridge and we set it to up. And then we set these firewall or forwarding rules that are quite gnarly to set up, but we've taken care of them for you.

And these decide how data flows from the host to the sandbox and back.

Another function here that takes care of port forwarding, and you can see we use Linux iptables command to do that. And

we have a destination port inside the guest, and we have this DNAT argument here that does all the magic. And we call this using goes command or run. Yeah. Okay, with networking set up, our updated architecture looks like this.

We have the REST server spawning these MicroVM sandboxes. And now we see that we've taken care of port forwarding. So a VNC client running on your MacBook or your laptop can easily access the GUI via the VNC server running inside the sandbox.

As mentioned before, we use Docker tooling to customize Arrakis sandboxes. So you can run whatever packages and binaries you want by just modifying a Docker file inside Arrakis. So let's take a look over the Docker file that we have by default.

And so you can see we base it on Ubuntu 22.04, have these standard packages inside for your agents to be productive without installing anything else at runtime. And you can see we also give you Chrome installed, and we boot it via systemd inside the sandbox.

And also install Node.js and NPM so that you can make Node apps. Python's also already installed. So the agents can do a lot with these tools inside the sandbox, and you can configure them in the future with whatever binaries you want inside.

Okay, let's put it all together and see how we create a VM in code. So as you can see, we create all the devices we talked about. So there's a root FS, there's the overlay FS writable path here.

We allocate some vCPUs, which are nothing but threads on your host OS. We calculate some memory and give it as a fraction of the host memory available. There's a networking device, so we created the tap device as well.

And above in the snippet, we also did the port forwarding. VSOC is a way to communicate between the guest and the host again. And then, yeah, finally, we spawned a VMM process and then called this createVM API on it with this configuration to start a guest VM.

As mentioned before, code exec is one of the very important functionalities of an AI sandbox. Arrakis comes in bundled with a code execution server. Here I show you the exact code that's running inside the code execution server. There's a files API to upload and download files.

We'll see in the Claude demo how this API is used liberally by Claude to send data back and forth. And there's, of course, a command API, which takes in a command, executes it, and returns either an output or error in the form of JSON.

We're running in a guest VM, so I'm much more confident about this code not escaping out. And we can be relaxed with it versus if we were running directly on top of our host OS, then I'd be very, very scared exposing something like this.

On top of the code execution server, we also have Chrome pre-installed. And like I said, we do port forwarding for you to your VNC server inside the sandbox. So you can actually access Chrome directly and the GUI directly inside your sandbox very easily with Arrakis.

Okay, now let's talk about one of the most exciting features of Arrakis, snapshotting. So what's the motivation behind saving state of a sandbox and snapshotting? So in general, agents fail when you're giving them a very big task like make me a Google News-like app because inevitably they fail somewhere during this big wake task.

So they need a step-by-step plan. And as specific and as small the plan, the better the reliability. But even then, multi-stage plans can fail. So imagine if you have a deep, almost like a dag of execution, you do all the work and you fail towards the very end.

You shouldn't have to start from scratch. You should be able to backtrack to the last good checkpoint, replan, and try again. So that's the motivation behind snapshotting, giving agents the capability to fail and backtrack, and then at scale getting more reliable results by exploring multiple paths in parallel.

So Arrakis lets agents save the entire running state of a sandbox. So this includes just the guest memory and the file system, which is the RW part of the overlay FS. So any files it created, any processes it spawned, all will be restored as is.

So imagine on your MacBook, if you close the lid and you open it up, it's exactly the same semantic. And so, yeah, any processes found, even Windows opened in the GUI, that's nothing but guest memory state. So they'll be restored as is.

And so agents can backtrack to a good snapshot if they fail and then replan and continue the workflow. So this diagram shows how we can do this at scale. If we fail, we can just go back to our path of execution to a last known good hash and replan and try again.

Currently, we don't use butter FS, but our plan is to use a file system that natively is aware of incremental snapshots and is optimized for such. And so we are exploring using butter FS instead of ext4 for the file system as well.

Now let's go over how we actually do the snapshotting in code. And there are four steps. We actually first pause the VM by calling the pause API on the VMM. Then we call the snapshot API and dump the guest memory.

And then out of band, we manually persist the thin read-write overlay FS to persist all the files that the sandbox or the agent created inside the sandbox. And finally, we resume the VMM. So we checkpointed it, and then we just ran the sandbox again.

So it keeps doing what it has done before. And you can see this in code,right? We go ahead and pause the VM here. We make sure we resume before we exit the function here. We create a copy of the stateful disk, which is the read-write layer of the overlay FS.

Yeah, and finally call snapshots, which dumps the guest memory for the VM and creates this magical experience when you resume it. Okay, we've gone through the entire architecture of Arrakis and how you would build an AI sandbox like Arrakis.

Let's put it all together. And how would we actually use it? So Arrakis comes with a first-class support for a Python SDK. So you pip install the pyarrakis package. And it's very simple from then on. You self-host Arrakis on your own infrastructure, give it the IP here to the sandbox manager.

You figure out what all VMs are running by calling the list all API that gives you metadata about the VM, its IP, its ports. You start a sandbox with the start sandbox API, run a command, and see the output or the error using the output or error JSON keys.

And here's how you can actually snapshot with just one command. You give a snapshot ID, and then you destroy the VM when you're done. And later on, when you want to actually restore the checkpoint from your snapshot, it's very simple.

You just call restore with your VM name, and you give the snapshot ID that you got here from the snapshot call. So all in all, a very simple API to use spawn and use AI sandboxes for code exec and other things.

Okay, so we've seen the architecture of Arrakis. Now let's see it in action. Let's see Claude desktop make a Google Docs clone using Arrakis via its MCP server. And you'll see that we don't have to do a whole lot of prompting or create a whole coding agent tool or framework.

It really does a lot of heavy lifting once it realizes it has access to a full-blown Linux sandbox. So yeah, let's go over the demo real quick.

So you can see I prompted to create a Google Docs clone, and that has collaboration built in. So multiple people can join. We'll see that on theright-hand side, we are running Arrakis. And off the blat, Claude is just piping commands.

It creates a sandbox and pipes commands directly in. It creates this Google Docs clone, and we have networking set up so people can type in together. We can snapshot this version as well. So we created a snapshot of that copy.

And now we try to add a feature on top of that clone. And so, yeah, we try to add dark mode inside the Google Docs clone.

Let's see Claude do this as well. Okay, let's see. So it added that dark mode feature inside, and you can see it works. Collaboration hasn't broken. But I changed my mind. I want to go back to the snapshot we had before without the dark mode.

And so you can see we can restore the old checkpoint and go back to without dark mode here.

Right, so the cool part here is that

it did the snapshotting, and you could see it created end-to-end apps without me prompting it again and again. But since we took care of networking, we could actually get a completely collaborative experience, like a full-on Google Docs thing versus just fake collaboration that other client-side code gen tools might do.

So that was one cool side effect of the demo. Yeah. Okay, let's discuss some of the ongoing work on Arrakis. Top of mind is definitely getting boot time to be under one second and even lower if possible. I know other sandboxes are also going on this metric.

Second is really, really have first-class support for snapshots and persistence. So what that means is moving to butter FS, which is tailor-made for incremental snapshots. And then we want to bin pack as many sandboxes on one server as possible.

So we need to do dynamic memory management and resource management. So ballooning or hot plugging or removal of memory at runtime is very, very important. Yeah, that's it for today. I hope you liked the presentation and you got a killing of why sandboxes are important, how they're made from scratch, and a taste of cutting-edge Linux systems work.

If any of this is interesting, please get in touch with me at those links. And I've left the links for the launch video, the GitHub repo. Yeah, happy to help anyone. Thanks so much. Bye.