Deploy long-running Node.js functions next to your database

Helps define, run locally, deploy, and manage Neon Functions - a preview feature (us-east-2 only) that runs long-running Node.js 24 HTTP handlers on a Neon branch, each with a public HTTPS URL, running in the database's region with DATABASE_URL injected automatically when the branch has Postgres. A function is any default export with a Workers/WinterTC-compatible fetch(request) method, so a Hono app's export default app works unchanged; adding an upgrade(req, socket, head) export alongside fetch lets the same function also terminate WebSocket handshakes. Functions are declared in neon.ts under preview.functions, keyed by an immutable slug matching ^[a-z0-9]{1,20}$, and reconciled the infrastructure-as-code way with neon config status/plan/apply (neon deploy is an alias) - branch-scoped exactly like other Neon services, with neon dev serving them locally with hot reload. Because an isolate is reused across many requests (several possibly in flight at once), the skill's core Postgres pattern is a pg pool via Drizzle created once at module scope with a small max (e.g. 5), using pooled DATABASE_URL for normal queries and unpooled DATABASE_URL_UNPOOLED for migrations, LISTEN/NOTIFY, or multi-statement transactions - never opening a connection per request. WebSocket servers are the canonical workload: hold connections open in-process with no external state store, but because each isolate has its own module state, broadcasting must fan out via Postgres LISTEN/NOTIFY across every isolate rather than a local in-memory set, and clients must be built to reconnect with backoff and a freshly-minted short-lived token on every attempt, since idle sockets get evicted. Server-sent events are the simpler alternative when only server-to-client streaming is needed - a plain fetch returning a ReadableStream with Content-Type: text/event-stream, with EventSource reconnecting client-side automatically. MCP servers map naturally onto a function's fetch handler via the streamable HTTP transport (@modelcontextprotocol/sdk plus @hono/mcp), authenticated with Better Auth's OAuth plugin or a simpler API-key check. Hard limits during preview: 15 minutes to first byte, 15-minute heartbeat window for open streams, 15-minute waitUntil ceiling for post-response cleanup work (not a background-job runner), idle eviction with a SIGINT warning, and fixed 2048 MiB memory.

Reach for Functions when a workload needs to outlast lambda-style limits - agents making several LLM/tool calls per request, image or video generation, stateful WebSocket or SSE streaming without bolting on Redis, or compute that must sit next to Postgres with no cross-region round trips. For an agent behind a full-stack app (Next.js/Remix on Vercel/Netlify), the critical pattern is calling the Function directly from the browser with a short-lived JWT rather than proxying the stream through the app server, since the app host's own short serverless limits would cut the agent stream off even though the Function itself wouldn't time out - and because the Function's URL is public, it must verify that JWT itself, never trusting an unauthenticated caller. It is not the right tool for a pure static site, a background/cron job needing its own lifecycle and cancellation, or anything that must run outside us-east-2 today.

Input is an HTTP request, WebSocket upgrade, or MCP tool call against the function's public URL. Output is a Response (JSON, SSE stream, or WebSocket connection), with DATABASE_URL and related branch-scoped variables injected automatically at runtime rather than declared at deploy time.

Deploys and manages through the same Neon CLI, neon.ts, and API as other branch services; integrates with Hono for routing, Drizzle/node-postgres for querying, the ws library or a Hono WebSocket adapter for real-time connections, @modelcontextprotocol/sdk for MCP hosting, Better Auth for authentication, and Sentry or Mastra Studio for observability - all standard Node SDKs work unchanged since a Function is a real long-lived Node process.

Developers building agent backends, WebSocket or SSE servers, or MCP servers that need to run longer than typical serverless limits allow and stay close to their Neon Postgres data, without standing up separate long-running infrastructure.