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

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 (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 (lines 103-110):

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.

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:

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

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

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 with real-world usage examples in 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, 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, which handles the actual Durable Object interactions backing each remote backend.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}