Cloudflare Workers

Walrus Memory runs on the Cloudflare Workers runtime, but the edge environment differs from Node.js in a few ways that affect bundling and reliability. The configuration and patterns below make it work cleanly.

What configuration does Walrus Memory need on Workers?

The SDK relies on the Node.js crypto built-in, and @mysten/seal and @mysten/sui pull in more Node APIs. Enable the Node.js compatibility flag in your wrangler.toml:

Source: sdk/cloudflare-workers.md

wrangler.toml

compatibility_flags = ["nodejs_compat"]

Without nodejs_compat the build fails outright: wrangler deploy stops with Could not resolve "crypto" because the SDK calls await import("crypto") internally. Adding the flag resolves it.

How large is the Walrus Memory bundle?

Even the default MemWal client requires @mysten/seal and @mysten/sui as peer dependencies (it builds a Seal session key on the client to authenticate each request), so it pulls in a sizeable dependency graph. A Worker bundling just the default client totals roughly 1.2 MB raw (around 225 KB gzipped), measured with wrangler deploy --dry-run against @mysten/sui 2.x. That is comfortably within the Workers size limit, but worth knowing:

• A single incompatible peer version can break the build for the entire Worker, not just the memory feature. Pin your @mysten/* versions and treat the memory dependency as a unit.
• The default @mysten-incubation/memwal entry point is the lightest to bundle. The relayer handles embeddings and Walrus storage server-side, so the client only needs @mysten/seal and @mysten/sui (both required peers). The @mysten-incubation/memwal/manual entry point additionally pulls in @mysten/walrus and client-side encryption and upload, adding more to the bundle. Prefer the default entry point on Workers unless you specifically need the manual flow.

How to isolate crashes with a dynamic import

To keep a Walrus Memory bundling or runtime issue from taking down the rest of your agent, load it behind a defensive dynamic import and feature-flag it off when config is missing or the client fails to come up. This way the app keeps serving requests even if memory is unavailable for a cycle:

Source: sdk/cloudflare-workers.md

let memwal: any = null;

try {
  const mod = await import("@mysten-incubation/memwal");
  memwal = mod.MemWal.create({ key, accountId, serverUrl, namespace });
  await memwal.health();
} catch (e) {
  console.log("MemWal unavailable, degrading gracefully:", e);
  memwal = null; // app keeps running without memory this cycle
}

Guard your read and write paths on memwal being non-null, and the rest of the Worker stays healthy regardless of the memory layer's state.

note

The dynamic import() also keeps the heavy dependency graph out of your Worker's cold-start critical path until memory is actually needed.

Verify memory operations in a Worker

A successful memwal.health() call resolves with a response that includes status and version fields. A failed call throws, so the catch branch of the defensive import handles it.

A passing health check only shows that the relayer is reachable. To confirm that memory operations work end to end from your Worker, store a memory, wait for the remember job, and then recall it:

const job = await memwal.remember("User prefers dark mode and works in TypeScript.");
await memwal.waitForRememberJob(job.job_id);

const result = await memwal.recall({ query: "What do we know about this user?" });
console.log(result.results);

If result.results contains the stored text, the full path works inside the Workers runtime. This path covers the Seal session the client builds on recall(). To keep test data separate from real memories, run the check in a dedicated namespace.