Invoking Entrypoints
Invoke JavaScript build handlers and experimental Go HTTP server entrypoints.
Node.js and Edge entrypoints use a handler(..., ctx) interface, with runtime-specific request/response types. Experimental Go entrypoints are compiled HTTP servers.
Node.js runtime (runtime: 'nodejs')
Node.js entrypoints use the following interface:
When invoking Node.js entrypoints directly, adapters can pass helpers directly on requestMeta instead of relying on internals. Some of the supported fields are hostname,
revalidate, and render404:
Relevant files in the Next.js core:
packages/next/src/build/templates/app-page.tspackages/next/src/build/templates/app-route.ts- and
packages/next/src/build/templates/pages-api.ts
Edge runtime (runtime: 'edge') (deprecated)
The Edge Runtime is deprecated. New routes should use the Node.js runtime.
Edge entrypoints use the following interface:
The shape is aligned around handler(..., ctx), but Node.js and Edge runtimes use different request/response primitives.
For outputs with runtime: 'edge', Next.js also provides output.edgeRuntime with the canonical metadata needed to invoke the entrypoint:
After your edge runtime loads and evaluates the chunks for modulePath, use entryKey to read the registered entry from the global edge entry registry (globalThis._ENTRIES), then invoke handlerExport from that entry:
Use edgeRuntime instead of deriving registry keys or handler names from filenames.
Relevant files in the Next.js core:
packages/next/src/build/templates/edge-ssr.tspackages/next/src/build/templates/edge-app-route.tspackages/next/src/build/templates/pages-edge-api.ts- and
packages/next/src/build/templates/middleware.ts
Go runtime (runtime: 'go')
With experimental route.go handlers, output.filePath identifies a native executable rather than a JavaScript module. Package it with the declared assets for the target operating system and architecture, preserving executable permissions and the asset destination paths.
The executable targets the build host's operating system and architecture, with CGO disabled. Build in an environment that matches the deployment runtime. Cross-compilation is not supported for Go routes.
Start the executable without arguments, set PORT to its assigned HTTP port, and use the packaged function directory as its working directory. The server listens on 0.0.0.0 so container and function ingress can reach it. The adapter owns network isolation. The adapter build's executable runs independently of the self-hosted Next.js server: it requires neither a private Next.js token nor a parent-owned stdin pipe.
Forward the final destination URL after rewrites and proxy processing, including its query string and any basePath. For example, a request for /alias?sort=asc rewritten to /users/123 must reach the Go server as /users/123?sort=asc. The handler's r.URL, r.RequestURI, and query reflect that destination, including any URL normalization the platform performs. Development and self-hosted deployments use the same destination URL contract.
Each executable contains only its own emitted route pattern. It matches the destination pathname and derives decoded dynamic and catch-all parameters from it. Escaped slashes stay within their original parameter segments. A pathname that does not match the emitted route returns 404.
The platform routes requests to the correct Go function and runs its own rewrite and proxy integration. Node.js outputs continue to use their existing handler interface. JavaScript callbacks such as ctx.waitUntil cannot be passed to the Go process; the initial server contract provides no completion guarantee for post-response work.