# How `ready({ all: true })` Pre-warms Backends in a Cloudflare Computer Workspace

> Discover how workspace.ready({ all: true }) pre-warms Cloudflare Computer Workspace backends by parallelly dialing RPC connections and caching handles to eliminate cold-start latency.

- Repository: [Cloudflare/computer](https://github.com/cloudflare/computer)
- Tags: internals
- Published: 2026-08-13

---

**Calling `workspace.ready({ all: true })` builds the mount index and eagerly dials every backend's RPC connection in parallel, caching handles to eliminate cold-start latency before any workload execution.**

In the `cloudflare/computer` repository, the `Workspace` class manages distributed execution across multiple backends. The `ready()` method serves as the critical initialization gate that ensures file system mounts are indexed and, when configured with `{ all: true }`, establishes eager connections to all defined backends before processing begins.

## The Mount Indexing Foundation

The first call to `ready()` creates a cached promise (`#readyPromise`) that executes `this.#mountIndex.ensureIndexed()`. This operation is the baseline side-effect of the `ready()` method, responsible for building the internal index of mounted paths regardless of which options are passed.

According to the source code in [`packages/computer/src/workspace.ts`](https://github.com/cloudflare/computer/blob/main/packages/computer/src/workspace.ts) (lines 73-84), this indexing happens exactly once per workspace instance and must complete before any backend connections are established. The cached promise pattern ensures that subsequent calls to `ready()` return the same indexing operation without redundant work.

## Parallel Backend Pre-warming with `{ all: true }`

When the caller passes `{ all: true }`, the method launches a parallel pass over every backend defined for the workspace. After the mount index finishes, the implementation invokes `this.#handleFor(backend.id)` for each regular backend and `this.#moduleHandleFor(id)` for each module-backend.

These arrays are built from the private fields `#backends` and `#moduleBackendsById` as implemented in [`packages/computer/src/workspace.ts`](https://github.com/cloudflare/computer/blob/main/packages/computer/src/workspace.ts) (lines 103-110):

```typescript
if (options.all) {
  return (async () => {
    await indexPromise;                     // wait for mount indexing
    await Promise.all([
      ...this.#backends.map(b => this.#handleFor(b.id)),
      ...[...this.#moduleBackendsById.keys()].map(id => this.#moduleHandleFor(id)),
    ]);
  })();
}

```

This parallel `Promise.all` execution ensures that all RPC connections are established simultaneously rather than sequentially, minimizing startup latency for workspaces with multiple backends.

## How Pre-warming Eliminates Cold Starts

The term "pre-warm" refers to the eager initialization of **backend handles** before they are actually needed for command execution. The `#handleFor()` method (and its module-backend counterpart `#moduleHandleFor()`) creates a `BackendHandle` if one does not already exist and immediately dials the Durable Object backing the remote service.

This process caches the RPC client within the handle instance. Subsequent calls to `exec()`, `push()`, `pull()`, or other workspace methods reuse the same connection without incurring additional network round-trips. By dialing all backends during the `ready()` phase, the workspace eliminates the first-use "cold-start" delay that would otherwise occur when accessing a backend for the first time during actual workload execution.

## Implementing Pre-warming in Your Agent

You can leverage pre-warming in agent startup hooks or manual initialization flows. The most common pattern involves calling `workspace.ready({ all: true })` inside an `onStart` hook to ensure all backends are reachable before processing begins.

```typescript
import { Workspace } from "@cloudflare/computer";

export async function onStart(ws: Workspace) {
  // Guarantees every backend is connected before any work runs
  await ws.ready({ all: true });
}

```

For targeted pre-warming of a single backend, pass the backend identifier directly:

```typescript
await ws.ready("my-backend");   // only “my-backend” is dialed

```

After pre-warming, subsequent operations execute without connection latency:

```typescript
await ws.ready({ all: true }); // all backends are live
await ws.exec("my-backend", "npm install"); // fast, no extra dial

```

## Summary

- **`ready({ all: true })`** triggers parallel initialization of all workspace backends after mount indexing completes.
- **Mount indexing** occurs via `this.#mountIndex.ensureIndexed()` and is cached in `#readyPromise` to prevent redundant work.
- **Backend handles** are created through `#handleFor()` and `#moduleHandleFor()`, which dial Durable Objects and cache RPC clients.
- **Pre-warming eliminates cold starts** by establishing connections before first use, reducing latency for critical path operations.
- The implementation resides in [`packages/computer/src/workspace.ts`](https://github.com/cloudflare/computer/blob/main/packages/computer/src/workspace.ts) with real-world usage examples in [`examples-compare-runtimes/worker/container-pool-manager.ts`](https://github.com/cloudflare/computer/blob/main/examples-compare-runtimes/worker/container-pool-manager.ts).

## Frequently Asked Questions

### What is the difference between `ready()` and `ready({ all: true })`?

Calling `ready()` without arguments only ensures the mount index is built, whereas `ready({ all: true })` additionally triggers parallel connection establishment to every configured backend. The latter eliminates first-use latency by dialing all Durable Object RPC connections during initialization rather than on-demand.

### When should I use pre-warming in a Cloudflare Computer Workspace?

Use `ready({ all: true })` when your agent requires predictable low-latency access to multiple backends immediately after startup, such as in `onStart` hooks for container pool managers or when running critical path operations against several remote services. If you only access backends sporadically or use just one specific backend, targeted pre-warming with `ready("backend-id")` may be more efficient.

### Does pre-warming affect performance if I only use one backend?

Pre-warming all backends when you only need one creates unnecessary connection overhead and consumes resources for unutilized services. In this scenario, pass the specific backend identifier to `ready()` rather than using `{ all: true }` to dial only the required service.

### Where is the backend connection logic implemented?

The core connection logic resides in [`packages/computer/src/workspace.ts`](https://github.com/cloudflare/computer/blob/main/packages/computer/src/workspace.ts), where `#handleFor()` and `#moduleHandleFor()` instantiate `BackendHandle` objects that manage Durable Object RPC connections. The underlying RPC server implementation is defined in [`packages/rpc/src/server.ts`](https://github.com/cloudflare/computer/blob/main/packages/rpc/src/server.ts), which handles the actual Durable Object interactions backing each remote backend.