How Replicas Cut Customer Latency 60% with E2B

Replicas runs coding agents in the cloud for engineering teams. Ping the agent from Slack, assign it a Linear ticket, or tag it on a GitHub PR, and it spins up an agent that clones the repo, installs dependencies, runs the actual stack, and comes back with a pull request. 

The premise sounds simple: give an agent a sandbox and let it write code. The hard part is that the agent has to run builds, boot databases, start dev servers, and use developer tooling, the same way an engineer would on their laptop. That means the environment underneath it can't just be a place to execute code - it has to be a computer.

The challenge

Agents need a full computer

Customers wanted the agent to behave like an engineer: check out a branch, run the build, start the services, hit the app, and verify the change actually worked before opening a PR. That workload needs memory, disk space, and an environment that stays up for the duration of the task.

“Agents need the same environment engineers have - a full computer. Those are big: a lot of memory, a lot of disk. Spinning up, running, and winding down a lot of large machines reliably matters a lot in use cases like ours.”

- Connor Loi, Founder, Replicas

Docker-based sandboxes slowed down the workload

Before E2B, Replicas ran in a Docker-based sandbox. That became a problem fast, because one of the most common things Replicas agents do is run Docker workloads themselves, spinning up services and containers inside their own environment. Nesting that on top of an already Docker-based sandbox made everything slower and heavier. Fixing it became a top priority, and it landed at the worst possible time.

The build-vs-buy moment came during a fundraise

Replicas was in the middle of fundraising toward the end of the P26 YC batch when their sandbox setup at the time started experiencing reliability issues. At this critical time, they simply wanted the product to work, and building it in-house was infeasible. Replicas first tried building on raw AWS EC2 instances, as well as five different sandbox providers before E2B. Of every option Replicas tested, E2B was both the fastest and most reliable to build on.

"I originally started with a competitor, but the search for something stable kept dragging on right as the team was heading into the end of its YC batch and preparing to fundraise. The sandbox infrastructure was basically the last thing I wanted to think about.”

- Connor Loi, Replicas

The solution

Warm pools turn a Slack ping into a running agent

Replicas captures each customer’s configured workspace as an E2B Snapshot, including the cloned repository, installed dependencies, and development setup. When someone pings Replicas in Slack or assigns it a Linear ticket, Replicas starts a new sandbox from that snapshot. The agent inherits the prepared environment and can begin working without rebuilding the customer’s development setup from scratch.

Why E2B: MicroVM isolation with room to grow

Replicas evaluated sandbox providers on more than raw functionality, since most of them looked similar on paper. What mattered was which one Replicas could still trust to be reliable five years out. That meant comparing licenses and how open-source-forward each provider actually was. E2B's MicroVM-based isolation, snapshots, and open-source architecture made it the one Replicas felt comfortable building on for the long term.

"We wanted an offering that balanced a focus on open source with stability and fast support, and that was E2B."

- Connor Loi, Replicas

It worked on the first try

The difference after switching sandbox providers showed up immediately. E2B was the only sandbox provider that worked on the first try, with no flakiness to debug afterward. It was easy for Replicas to get set up on E2B, and the timing made it even more important: their sandbox headaches were resolved in the final, highest-stakes week of the YC batch, freeing Loi to stop thinking about infrastructure entirely.

The results

• Latency cut by more than 60% for customers running heavy workloads on Replicas after switching to E2B.
• 3 weeks saved on debugging sandboxes during the final stretch of YC and fundraising, when any time diverted from the product was costly.
• 20+ YC companies now run their engineering work through Replicas.

"Reliability is the only thing that matters, and lack of reliability was the main reason for churn at Replicas. You want to pick infrastructure that's never going to let you down, so you have time to work on the thing that matters most: the agent experience."

- Connor Loi, Replicas

Looking ahead

Replicas is building toward a future where fleets of agents run entire engineering workflows end to end, triaging tickets, writing code, responding to CI failures and review comments, and merging without anyone in the room. That only works if the computer underneath each agent is one Replicas doesn't have to think about. As Replicas takes on larger engineering teams and enterprise contracts, it's leaning further into E2B's MicroVM isolation and the flexibility of running workloads in their own cloud to keep every agent's environment as reliable as the ones engineers already trust on their own laptops.

‍