Next.js standalone builds move the Sentry source-map upload onto your own build machine

The ordering constraint does the design work here. A standalone deploy is a copy operation: `output: "standalone"` emits a self-contained bundle, you copy it into a container, and you start it with `node .next/standalone/server.js` ^[3]. Anything absent from that copy does not exist at runtime. Anything present in it is reachable by whoever can fetch a static asset ^[5]. Serving maps beside the bundle is a quiet way to open-source a project. So a `.map` file has exactly one window:

1. The build emits it. 2. The build uploads it to Sentry. 3. The build deletes it before the image is sealed.

Rogulia writes that `@sentry/nextjs` performs both the upload and the deletion, but only when the build is configured for it ^[6]. His published text stops before the build options themselves, so the option names are the part you still confirm against the SDK version you install. What the post does show in full is the runtime wiring, and that is where a suspiciously calm Sentry project usually comes from.

Next.js runs route handlers and Server Components on Node and middleware on the Edge runtime, so Sentry initialises separately in each ^[7]. `instrumentation.ts` executes once per runtime at server startup: `register()` branches on `NEXT_RUNTIME` and dynamically imports `sentry.edge.config` for Edge, or `sentry.server.config` plus `instrumentation.node` for Node ^[8]. The dynamic import is load-bearing. A static one pulls the Node SDK into the Edge bundle, where half its dependencies do not exist ^[9]. Count the registration file, the two runtime configs and the process-handler module and that is four files standing between you and a captured error ^[16].

The export sitting below `register()` is `onRequestError = Sentry.captureRequestError`, which attaches Sentry to the framework hook that fires when a route handler, a Server Component render or a Server Action throws ^[10].

One default is worth reading before you trust a dashboard: `tracesSampleRate` is 0.1 in production against 1.0 in development ^[12], a tenfold gap, so a path you trace comfortably on your laptop is ten times likelier to be recorded there than in production ^[15]. `includeLocalVariables` captures variable values inside the frames, which is what turns an undefined-property TypeError into something you can reason about ^[13].

This is one practitioner's config rather than vendor documentation, so treat the specific values as his. What transfers is the split itself, and that is a property of `output: "standalone"` ^[3], not of Sentry: the moment the build machine stops being the run machine, every step a platform integration used to perform between them becomes a line in your own pipeline ^[4].