Serverless

Install NextRush and the serverless adapter

• Why this matters: like the other non-Node runtimes, the nextrush meta-package does not bundle a runtime adapter — you add @nextrush/adapter-serverless alongside it.

$ pnpm add nextrush @nextrush/adapter-serverless

Behind the scenes:

• createApp and createRouter still come from nextrush — runtime-independent
• createLambdaHandler comes from @nextrush/adapter-serverless — the meta-package's listen targets @nextrush/adapter-node specifically
• Covers AWS Lambda Function URLs and both API Gateway payload formats (HTTP API v2, REST API v1) — auto-detects which event shape it received
• Google Cloud Functions and Azure Functions have their own handlers (createGoogleHandler, createAzureHandler) from the same package

Write a hello-world Lambda handler

Create index.ts:

import { createApp, createRouter } from 'nextrush';
import { createLambdaHandler } from '@nextrush/adapter-serverless';

const app = createApp();
const router = createRouter();

router.get('/', (ctx) => {
  ctx.json({ runtime: ctx.runtime, status: 'ok' });
});

app.route('/', router);
export const handler = createLambdaHandler(app);

Deploy behind a Lambda Function URL (or API Gateway) using your usual AWS tooling.

✅Expected result — curl https://your-function-url.lambda-url.us-east-1.on.aws/ returns {"runtime": "edge", "status": "ok"}

Behind the scenes:

• createLambdaHandler(app) wires AWS event mappers and reuses the edge adapter's fetch engine
• ctx.runtime reports 'edge' because the handler is built on @nextrush/adapter-edge's fetch engine
• The handler shape ((event, context?) => Promise<result>) is the plain AWS Lambda contract — no NextRush-specific deploy step needed

Build the handler at module scope

• Why this matters: where you call createApp() and createLambdaHandler() determines whether warm-instance reuse actually helps.

Keep app construction at module scope, never inside the handler function:

import { createApp, createRouter } from 'nextrush';
import { createLambdaHandler } from '@nextrush/adapter-serverless';

// Module scope — runs once per cold start, reused across every warm invocation.
const app = createApp();
const router = createRouter();
router.get('/', (ctx) => ctx.json({ status: 'ok' }));
app.route('/', router);

export const handler = createLambdaHandler(app);

What changes with per-invocation execution

Your handler is deployed. Before moving on, understand what's genuinely different.

Same: the Context API, createApp, createRouter, route registration, and middleware all behave identically to Node. Nothing in your route handler is Lambda-specific, and the same app code moves to Google Cloud Functions or Azure Functions by swapping createLambdaHandler for createGoogleHandler or createAzureHandler.

Different: there is no long-running process — the platform invokes your handler per event and may terminate the environment between invocations. The first invocation on a fresh instance pays a cold-start cost (app.ready() for the first time); warm invocations on the same instance skip it. createLambdaHandler buffers the full response body; for true streaming (lower time-to-first-byte), use createLambdaStreamingHandler instead.