Transitioning Wire Away from Cloudflare Durable Objects

Wire provides context containers designed for AI agents. These act as isolated repositories for processed intelligence—including embeddings, provenance graphs, and knowledge entries—which are accessed via the Model Context Protocol (MCP).

Since inception, these containers were powered by Cloudflare Durable Objects (DO). However, we have since engineered a custom runtime from scratch. After rigorous benchmarking using identical data and judges, we are now migrating our initial workspaces to our own proprietary data plane.

Note: We still value Cloudflare. Our API, frontends, control plane, and general processing continue to run on Workers.

The Dilemma: Why Leave?

Durable Objects are an incredible tool for managing thousands of small, mostly dormant stateful units. In terms of development velocity, they are nearly unmatched. However, we hit four critical walls:

1. The Vector Gap

Retrieval is the core function of a container. Previously, embeddings were stored in Vectorize (a separate service). This created:

• Local data access $\rightarrow$ A network hop on the most critical path.
• State synchronization risks (potential for drift).
• Limitation: DO SQLite does not support extensions, meaning the index could not be moved inside the object.

2. Compute-Data Locality

Retrieval isn't a single step; it's a pipeline: $\text{Hybrid Generation} \rightarrow \text{Fusion} \rightarrow \text{Query Expansion} \rightarrow \text{Wide Rerank}$

With DOs, only a tiny fraction of this logic lived with the data. The rest was offloaded to external services, adding variance to the critical path of agent tool loops.

3. Rigid Placement & Isolation

• Static Location: Placement is decided at creation. If a container is spawned in London, it stays there, even if the agent fleet calling it is in Virginia.
• Shared Resources: We lacked the ability to offer "isolation as a tier" (e.g., dedicated machines for premium workspaces).

4. Sovereignty

Regulated clients frequently require the ability to self-host their containers on infrastructure they fully control—something impossible with a proprietary platform like DO.

---

The New Architecture

We have shifted to a model where each organization is assigned a single host process running Bun on Fly Machines.

Technical Specifications

• Storage: Each container is a single SQLite file. We integrated sqlite-vec to keep the vector index embedded, allowing candidate retrieval to happen in-process.
• Persistence: We use snapshots stored in object storage, ensuring a container can be reconstructed byte-for-byte anywhere.
• Routing: A regional router ensures containers are placed near the caller.
• Security: The control plane communicates with the data plane via signed requests, ensuring it never touches actual container content.

---

Performance Benchmarks

The transition yielded significant improvements in latency and accuracy.

Regarding the wake-up time: this isn't a "cold start" issue (isolates wake in ms), but rather the end-to-end time to readiness.

The "Honest Read" on Recall

The jump in $\text{Recall@5}$ isn't solely due to architecture; we also upgraded our embedding model. However, the new architecture makes expensive operations affordable. In-process retrieval allows us to over-fetch and rerank widely, and small per-container indexes enable exact nearest-neighbor search.

---

Reclaiming Durability

Durable Objects provide single-writer consistency and durability out of the box. Moving away meant we had to "buy" these guarantees back through engineering.

The Failure Point: Our initial version was only "durable at the next checkpoint." During soak tests where we intentionally killed machines under load, we discovered that several acknowledged writes were simply lost.

The Solution: We implemented a stricter write-ahead log (WAL) protocol:

-- Conceptual logic for the new durability layer
BEGIN TRANSACTION;
-- 1. Write to WAL
-- 2. Sync WAL frame to Object Storage
-- 3. ACK to client only after storage confirmation
COMMIT;

By using group commit, we keep this overhead to roughly $100\text{ms}$, ensuring that a crashed machine cannot take acknowledged data with it.

---

Current Status & Roadmap

The migration is transparent to the end-user. We've maintained the same URLs, REST APIs, and MCP tools. Agents continue calling the same addresses; only the underlying runtime has changed.

Migration Checklist:

• Beta launch (Preview environment)
• Opt-in production workspaces
• Full production migration (pending durability "tripwires")
• Open-source the container runtime

Wire: Transforming documents into structured, AI-optimized context containers.