Cloudflare Workers & Edge

Edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy) freeze the isolate between invocations. There is no process.beforeExit, no SIGTERM — no reliable lifecycle hook. The pattern: use the runtime’s keep-alive primitive to await the flush after the response returns.

Cloudflare Workers

import { leadContract, logger } from "./boundary";

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const result = await leadContract.accept((attempt) => runLLM(attempt));
    const response = result.ok
      ? Response.json(result.data)
      : Response.json({ error: result.error.message }, { status: 422 });

    ctx.waitUntil(logger?.flush(1000) ?? Promise.resolve());
    return response;
  },
};

ctx.waitUntil keeps the isolate alive until the promise resolves, without blocking the client’s response. The user sees the response immediately; the flush finishes in the background up to the CPU/wall-clock limits of your Worker.

Vercel Edge Functions

Vercel Edge exposes the same waitUntil via @vercel/functions:

// app/api/score/route.ts
export const runtime = "edge";

import { waitUntil } from "@vercel/functions";
import { leadContract, logger } from "@/lib/boundary";

export async function POST(request: Request) {
  const result = await leadContract.accept((attempt) => runLLM(attempt));
  const response = result.ok
    ? Response.json(result.data)
    : Response.json({ error: result.error.message }, { status: 422 });

  waitUntil(logger?.flush(1000) ?? Promise.resolve());
  return response;
}

When @vercel/functions isn’t available (older Next versions), you can await the flush before returning — the user sees the extra latency, but events still ship:

await logger?.flush(1000);
return response;

Initialization

Module-scope initialization runs once per isolate. A single logger is reused across invocations on the same isolate — treat it the same way you’d treat a connection pool.

// boundary.ts
import { createBoundaryLogger } from "@withboundary/sdk";

export const logger = createBoundaryLogger({
  apiKey: globalThis.BOUNDARY_API_KEY,  // injected via env
  batch: {
    size: 10,
    maxQueueSize: 100,     // tighter memory budget than Node
    intervalMs: 0,         // disable timer — waitUntil handles drain
  },
});

Disabling the timer (intervalMs: 0) is recommended on Edge. The isolate freezes between invocations, so the timer is unreliable anyway.

Why `createBoundaryLogger` works without `process.env`

The SDK reads BOUNDARY_API_KEY from process.env when it’s defined. On Cloudflare Workers, process.env doesn’t exist — you have to pass the key explicitly:

// Don't do this on Workers — process.env is undefined
const logger = createBoundaryLogger({
  apiKey: process.env.BOUNDARY_API_KEY,  // throws or returns null
});

// Do this — pass the env the Worker gave you
export default {
  async fetch(request, env, ctx) {
    const logger = createBoundaryLogger({ apiKey: env.BOUNDARY_API_KEY });
    // ...
  },
};

If you want the logger at module scope (faster, reuses transport state), stash the env on globalThis from the first fetch invocation. Or use wrangler.toml bindings and pass through a factory:

let _logger: BoundaryLogger | null | undefined;

export function getLogger(env: Env) {
  if (_logger === undefined) {
    _logger = createBoundaryLogger({ apiKey: env.BOUNDARY_API_KEY });
  }
  return _logger;
}

Runtime detection on the wire

Each event’s sdk.runtime field will be undefined on Cloudflare Workers — there’s no process.versions.node and no navigator.userAgent in the isolate. That’s expected.

CPU / wall-clock budgets

Cloudflare Workers: up to 30s of wall-clock, 50ms-30s of CPU time depending on plan. ctx.waitUntil runs within those budgets — a slow flush still counts. If your flush commonly exceeds the budget, lower the batch size:

batch: {
  size: 5,            // smaller batches flush faster
  maxQueueSize: 50,
}

Durable Objects

Durable Objects have the same runtime shape as Workers. Same pattern — initialize in the class, flush via ctx.waitUntil in each method that could queue an event.

Deno Deploy

Pattern is identical — use Deno.serve and call await logger.flush() before returning. Deno Deploy does expose queueMicrotask / timers, but freezes between invocations like other edge runtimes.

Vercel / Lambda

Serverless Node runtime pattern

Batching

Tune size and maxQueueSize for Edge

Operate In Production

Runtime Platforms

Advanced

Cloudflare Workers & Edge