Opencomputer: Open source Devin alternative

Today we’re introducing OpenComputer, the open source and self-hostable alternative to Devin.

In March 2026 we introduced the idea of moving from “sandboxes” to “computers”. Our idea was simple: after looking at the landscape we realized that most sandboxes at the time always had a timeout that one needed to work around.

So we introduced our QEMU based sandboxes that are based on fully fledged VMs. Unlike other providers who chose to rely on S3 backed filesystems for their workloads, we realized that IOPS and disk speed are also an important feature for cloud agents, especially ones that perform code related tasks. What we also realized back then is that a slow disk is not acceptable, and in many ways we were right.

However, a local disk or block device meant dealing with a different tradeoff: the durability of the VM. It also made certain tasks such as snapshotting and forking VMs relatively harder than if we had chosen an S3 backed disk.

Fun fact: our initial name for the project was “opensandbox”, however we quickly realised that we are not a sandbox, we are a full computer, hence it became OpenComputer.

Specialized sandboxes: the golden opportunity

As we started onboarding users onto our generic sandboxes we quickly realized that we had multiple cohorts of users using it for different use cases: RL training, OpenClaw hosting, software factory sandboxes, CI/CD jobs. Surprisingly we also had a user who wanted to host a fleet of WordPress sites on our infrastructure! Each of these workloads has very different demands and requirements. This made it very clear that the market of sandboxes is not really one market, rather five or six very different use cases. Each of these required different profiles of CPU, memory, burstability, disk and concurrency. If we claimed to support all these workloads we would be doing injustice to ourselves and our users.

It was not hard for us to see that any general sandbox offering would not last long before it had to specialize into a use case, so we decided to focus on sandboxes for coding and software factories. In doing so we also naturally graduated up the stack, because offering a VM that can be forked is only one piece of the software factory puzzle. As we specialized, we discovered many nuances in the building blocks around software factories, and went on to offer more than raw sandboxes.

OpenComputer: an open source, self-hostable alternative to Devin

OpenComputer, today, has evolved into an open source, self-hostable alternative to Devin, from the compute layer all the way to the top. This means that organizations can self-host it completely within their own cloud account.

Self-hosting is available for Azure, AWS, GCP and OCI, and soon on Kubernetes. We have gone to great lengths to make self-hosting easy: at the limit, it is possible to self-host the whole thing on a single VM.

While it is an alternative, it is not a like-for-like copy of all of Devin’s features. In many cases we have applied our own taste and judgement to the product.

Applying taste: speed matters!

What we realized after a few iterations is that in many sessions it is very important to have quick and snappy responses from the agent. In our tests we tried several architectures:

• 1.The harness in a Durable Object on Cloudflare, the sandbox in AWS.
• 2.The harness and sandbox together in AWS microVMs.
• 3.The harness and sandbox together in a durable VM.

In the first case the slowness came from the many round trips between the harness and the sandbox. Imagine every bash or grep needing a network round trip. This made it far slower.

The second case worked, but again: making a sandbox’s disk durable meant moving it to S3, which causes random latency spikes whenever a path is not in the cached disk.

What we found in general is that the third setup responded and completed tasks up to 3x faster. In our benchmark of cloud coding agents, OpenComputer made its first push in 24s against 53–72s for the others, and had all four PRs open with CI green in 56s against 85–185s. Of course, you might be wondering how important it is to be interactively responsive. What we found working with users is that most coding work involves a lot of back and forth and planning, and there speed matters a lot. Another case is investigating an incident or an outage: you really want the agent to investigate as fast as possible, and having a session respond and gather data quickly is critical.

Then there are cases such as background tasks or small PRs where latency doesn’t matter, and waiting a minute won’t make a difference.

Sandboxes and the software factory

Our initial prototypes of an “open source software factory” had pluggable sandboxes from the existing providers. What we quickly realized was that a lot of those providers are completely unsuitable. We saw several roadblocks:

• —Startup times were way too slow for an interactive coding session.
• —For many enterprises, dependence on a third-party vendor is an instant blocker.
• —Self-hosting an entire sandbox platform within the enterprise is too complex.

And in reality a sandbox is simply an isolation strategy for a session. A container is an isolation strategy, and so is a VMM or Firecracker. Interestingly, for an internal software factory one can argue about what the right boundary of isolation is. For example, you could argue that the boundary is actually a complete VM for the entire team.

And this checks out, since a team probably shares repos, metrics and other access, which means the VM will always have the right cache available. We can then add the right isolation on top of it. In our experience this ends up being faster, more durable, simpler to maintain and in some cases cheaper.

Different compute for different needs

If we look at the activities of a coding agent, they are very different. For example, here are the typical activities that go into a normal PR flow:

• —clone the repo
• —grep across different files, explore the repo and figure out a task
• —modify some files, make some edits
• —push to a branch
• —run some light lint
• —run a heavy build (for example a Rust compile)
• —attempt to provision a preview environment (a light npm process, a heavy multi-stack Docker setup, or anything in between)
• —check for CI builds

The compute (memory, disk, CPU) requirements for each of these steps vary significantly. For example, when modifying files we really need a fast disk, and not so much memory. For a Rust build we need heavy memory and caching. For a preview environment it depends: sometimes we prefer to do it on a separate layer like ECS or a Kubernetes namespace, sometimes it’s preferred to do it locally.

The point here is that for most of the glue coding tasks and edits, we found that a single VM for the team performs best, is cheaper, and is also secure. A single VM can tolerate hundreds or thousands of sessions in parallel. When a heavy build task comes along, the VM can delegate it to a “specialized sandbox” such as a CI system or one of today’s sandbox vendors.

Running every session in an isolated sandbox is wasteful, since we allocate a large amount of memory for the entire session even though the session might end up changing a single line of documentation.

Stateless stateful VMs

The mental model around using sandboxes for coding is incorrect. In many cases we think of launching a version, snapshotting it, then destroying it when idle. There are several problems with this. The first is that to make this efficient we would keep the disk in an S3 store, relying heavily on caching. This has a huge penalty on general disk performance, especially for writes. In our tests this can make the agent 3x slower at creating a PR.

The second issue is that snapshot performance degrades as the VM gets larger. The third is that it gets even more complex with multi-repo setups: do you snapshot the machine for all repos or only a few, and what about caches such as npm packages? Do we keep those in or out of the snapshots?

We have a different take here. We asked the question: what if the VM was always on with a persistent disk, yet still stateless? What we mean is that at any point we can reconstruct previous sessions in a new VM, yet the disk is stateful and aggressively caches recent packages, repos and other data, so it is always instant. All session files are backed up to a repo after each turn.

We found this strategy to work extremely well, for our early adopters and internally: it just feels as fast as interacting with local Claude Code. Keeping the VMs stateless also means that they can scale horizontally with ease, and sessions can move from one VM to another if a VM is overloaded.

An ASG pool can be cheaper than an ephemeral sandbox per session

One might wonder whether a reserved VM with lower utilisation is cheaper or more expensive than an ephemeral sandbox for each session’s turn. Surprisingly, or not so surprisingly, it depends on how much your agents work. Our math shows that at around 640 session-hours a month, about four engineers each keeping an agent busy through the working day, a single always-on 4 vCPU VM becomes cheaper than an E2B sandbox per session, in addition to all the benefits mentioned earlier.

The chart below is a per-session price comparison between an E2B 2 vCPU / 8 GiB sandbox and an always-on VM that handles the sessions. It conservatively assumes each 4 vCPU VM runs two sessions at a time around the clock, and proportionally more on larger VMs. In practice most sessions sit idle between turns, so a VM fits many more and the savings grow. Of course, the numbers will vary: always-on VMs autoscale on sustained load and memory pressure, and scale down the same way.

It’s now fully open source

OpenComputer is now fully open source. You can self-host it on AWS, GCP or Azure, or try it via our cloud. On cloud, you get 3 days / 600 work minutes free to try it out, and can bring your subscription with you.

Check out the repo on GitHub and the docs for the details: how it works, the architecture and how to self-host it. Or book a time with the founders, we’d love to walk you through it.

Go and try it out and let us know what you think! We’re very hungry for feedback.