Skip to main content
Next.js has three runtimes: Node (default for route handlers, server actions, server components), Edge (opt-in via runtime = "edge"), and the browser. The SDK works in all three, but the wiring differs.

Where to initialize the logger

Put it in a single module and re-export. This avoids creating multiple loggers per request under the file-scoped import caching that Next does.

App Router — Route Handlers (Node runtime)

Flush per request. Next’s serverless Node invocations freeze quickly after the response is returned — beforeExit is not guaranteed to fire.

App Router — Route Handlers (Edge runtime)

On the Edge runtime, process.beforeExit does not exist. ctx.waitUntil is not exposed directly in App Router handlers — flush explicitly.
On Edge, tighten the capture policy — there’s no filesystem, no long-running process, and memory is bounded tighter than on Node.

Server Actions

Same pattern as route handlers — flush before returning.

React Server Components

Server components run once per request on the server. Same flushing rules apply — if your RSC invokes a contract, flush at the end.

Middleware

Next middleware runs on the Edge runtime. Don’t wire a logger here — middleware is for routing / headers / auth. If you somehow need to observe middleware decisions, use a custom write sink that posts to your own endpoint instead of Boundary directly.

Client components

Browser-side contracts are legitimate (e.g. validating an LLM response streamed directly to the client). Use the browser platform guide. Never pass an API key into the client bundle — NEXT_PUBLIC_* env vars are exposed to users. Either:
  • Wire the logger server-side only, or
  • Use a custom write that POSTs to your own authenticated server route.

Environment detection

Useful snippet for environment:

See also

Vercel / Lambda

Per-invocation flush pattern

Browser

Client-side contracts