Neon Functions

Neon Functions are serverless compute you deploy onto a Neon branch, so your backend code runs right next to your database. Use them to host an API, an AI agent, a real-time server, or a webhook handler without standing up separate infrastructure.

What makes Neon Functions different from lambda-style serverless?

• Next to your data. Same region as the branch, with DATABASE_URL (plus AI Gateway and Object Storage credentials) injected automatically. No cross-region hops, and no credentials to wire up.
• Long-running. Start responding within 15 minutes, then keep streaming while data flows, so agents and WebSocket/SSE servers aren't cut off by a short execution limit. They're still serverless: idle functions can be evicted (see Runtime limits).
• Branches with your data. Each branch runs its own function at its own URL against its own database state.

Functions run on Neon's own compute platform, the same infrastructure that runs your Postgres, so they sit in the same region as your data.

Functions are in beta and available only in AWS US East (Ohio) (aws-us-east-2), so create your project there to use them. Functions are free to use during beta, subject to usage limits, on any plan.

Get started

• 

  Quickstart

  Deploy your first function and call it over HTTP in under 5 minutes.

• 

  AI agents

  Run streaming, tool-calling AI agents next to your data.

• 

  WebSockets and SSE

  Hold long-lived connections open with WebSockets or SSE.

• 

  Authentication

  Verify callers before a function does any work.

• 

  Environment variables

  Neon-injected variables and how to add your own secrets.

• 

  Deploy and manage

  CLI and API reference for deploying and managing functions.

• 

  Logs

  View, search, and download a function's logs in the Console.

• 

  Runtime limits

  Timeouts, slug constraints, memory, and other hard limits.

Request/response, not background jobs

A function is always requested (by a fetch, a browser, an agent) and always returns a web response: JSON, an HTTP stream, an SSE feed, or a WebSocket upgrade.

That makes functions a fit for request/response work, and not for background jobs. Background jobs and workflows are the other kind of compute: queued, retryable, cancellable work with its own lifecycle, like sending a welcome email after signup. Those need a job queue or workflow engine to own that lifecycle. Today you can pair a function with a third-party queue or scheduler like Upstash QStash or Inngest: the service owns the queue, retries, and scheduling, and invokes your function over HTTP to run each job. A native Neon job queue and workflow engine is a separate, upcoming offering.

Any module whose default export provides a fetch(request) method that returns a Response is a function. It embraces the web platform standards: the Fetch API's Request and Response interface, the same handler shape used by other serverless runtimes and standardized by WinterTC. That can be an object with a fetch method:

export default {
  fetch: (request: Request) => new Response('Hello world'),
};

Or a bare async function:

export default async function handler(request: Request) {
  return new Response('Hello world');
}

A Hono app exports the object shape, so export default app works directly. Hono is the recommended framework.

When to use Neon Functions

• REST APIs and CRUD backends: request in, JSON out, queries running next to Postgres. See Quickstart.
• AI agents: stream tokens back across multiple model calls and tool invocations without a short execution limit cutting the run off. See AI agents.
• Real-time apps: WebSocket servers for chat and presence, or SSE for live updates. See WebSockets and SSE.
• MCP servers: expose database-backed tools to AI clients over a single fetch endpoint. See the with-mcp example.
• File upload APIs: receive a file, write it to Object Storage, return a result.
• Webhook handlers and bots: receive events and query Postgres in the same region.

How Functions fit with your app

Functions are backend primitives, not full-stack app hosting. Host your app on Vercel, Netlify, or another frontend host; reach for a function for the long-running, stateful slice of your backend that belongs next to your data. Two common shapes:

• Add a function to a full-stack app. Your Next.js or TanStack Start app owns the UI, auth, and most routes. When one workload outgrows the host's short serverless limit (a WebSocket or SSE server, or a long-running agent), move only that piece onto a function and call it directly from the client. See Authentication for the direct-call pattern.
• Run the backend on functions. When the frontend is client-only (a React or TanStack SPA), the client calls functions directly: REST APIs, request/response agents, MCP servers, and anything stateful that belongs close to Postgres and Object Storage.

Starter templates

Each example is a complete, runnable build. Read the source on GitHub, or scaffold one with neon bootstrap --template <id> (it copies the files, links a Neon project, and pulls env vars). You can also browse them at build-on-neon.vercel.app.