vercel-functions

// app/api/hello/route.ts — no runtime export needed.
export async function GET() {
  return Response.json({ message: 'Hello from Node.js on Fluid Compute' })
}

Node.js is the default. Omit export const runtime entirely rather than writing export const runtime = 'nodejs'.

• No fs, no native modules, no require() — ESM only, and most npm packages with Node.js dependencies simply will not load
• No eval / new Function / dynamic WebAssembly.instantiate
• Code size limit after gzip: 1 MB (Hobby), 2 MB (Pro), 4 MB (Enterprise) — versus 250 MB uncompressed (up to 5 GB) on Node.js
• Must begin sending a response within 25 seconds (it may then stream for up to 300s). The 300s/800s/1800s duration limits below apply to the Node.js, Bun, and Python runtimes — not to Edge
• No long-duration or large-function support of any kind

Worth doing when you're already touching the file, and required on Next.js 16.3+. An Edge function that works today isn't an emergency.

1. Remove export const runtime = 'edge' (or runtime: 'edge' in vercel.json / the config object).
2. Replace next/server Edge-only imports where applicable; the Web Request/Response handler signature is unchanged, so most route handlers need no other edit.
3. If you pinned execution with the Edge-only preferredRegion, use regions in vercel.json instead.
4. Confirm Fluid Compute is on (default since April 23, 2025) and redeploy.

There is no rollback story to plan for: Node.js is a superset of what the function could do on Edge.

• Full Node.js runtime, all npm packages available
• Default for Next.js route handlers, Server Actions, Server Components, and any file in /api
• Node.js 24 LTS is GA for builds and functions (V8 13.6, global URLPattern, Undici v7, npm v11). Node.js 20 is deprecated on October 1, 2026 — move off nodejs20.x
• Duration: 300s default on every plan; 800s max on Pro/Enterprise; 1800s with the extended-duration beta

Add "bunVersion": "1.x" to vercel.json to run functions on Bun instead of Node.js. ~28% lower latency for CPU-bound workloads. Supports Next.js, Express, Hono, Nitro, and Bun.serve as an entrypoint. Bun supports both large functions and extended max duration.

Python 3.12 / 3.13 / 3.14 on Fluid Compute. FastAPI, Flask, and Django build into a single function from the resolved entrypoint — key vercel.json config on that entrypoint file (app/main.py, myproject/wsgi.py), not on /api routes. Python gets a 500 MB standard bundle limit (vs. 250 MB) and supports large functions and extended duration.

Rust functions run on Fluid Compute with HTTP streaming and Active CPU pricing. Official runtime (Beta) built on the vercel_runtime crate. Supports environment variables up to 64 KB.

Any OCI image via Dockerfile.vercel. See Docker and Container Images below.

V8 isolates with a subset of Web APIs. Fine to leave in place on existing deployments, but not the runtime to pick for new work. See Prefer Node.js over the Edge runtime.

edge is deliberately absent: there's no row here where it's the better answer for new code.

• With Fluid Compute enabled, memory cannot be set in vercel.json — setting it there produces a build-time warning. Set it in the dashboard instead: Settings → Functions → Advanced Settings → Function CPU, then redeploy. (The memory key still exists for legacy non-Fluid deployments, which is why you will find older examples using it.)
• Pro/Enterprise only. Hobby always runs Standard (2 GB / 1 vCPU) and cannot configure it. The Basic instance has been removed.
• More memory also means more CPU, which can reduce Active CPU billing for CPU-bound work by finishing sooner — but it raises Provisioned Memory cost while requests are in flight.
• Projects created before 2019-11-08 may still sit on legacy sizes (1024 MB / 0.6 vCPU on Hobby, 3008 MB / 1.67 vCPU on Pro) until you pick a size in the dashboard.

Function code (export const maxDuration) → vercel.json → dashboard → Fluid defaults. Later entries lose.

waitUntil takes a Promise, not a callback. Passing a function does nothing — a common and silent bug.

import { waitUntil } from '@vercel/functions'

export async function POST(req: Request) {
  const data = await req.json()

  // Correct: invoke the async work and hand over the promise.
  waitUntil(processAnalytics(data))

  // For several tasks, combine them:
  waitUntil(Promise.all([sendNotification(data), updateCache(data)]))

  return Response.json({ received: true })
}

// Runs on scale-down. 500 ms to clean up (30 s for container images).
process.on('SIGTERM', () => {
  // flush buffers, close pools
})

Request cancellation is opt-in, per path. With it enabled, a client disconnect aborts request.signal and terminates the function — anything not wrapped in waitUntil/after is lost, which is exactly why it is not on by default.

{
  "functions": {
    "api/*": { "supportsCancellation": true }
  }
}

export async function GET(request: Request) {
  // Pass the signal through so upstream work stops too.
  const res = await fetch('https://upstream.example.com', { signal: request.signal })
  return new Response(res.body, { status: res.status })
}

With Fluid Compute (default), per Vercel's limits:

The 800s maximum is generally available on Pro and Enterprise. The 1800s extended maximum is in beta. Exceeding the limit returns 504 FUNCTION_INVOCATION_TIMEOUT.

Hobby's default and maximum are the same 300s — there is no headroom to raise, and no extended duration. Setting maxDuration above 300s on Hobby does nothing; upgrade to Pro.

// app/api/report/route.ts — Next.js App Router (and Node.js, SvelteKit, Astro,
// Nuxt, Remix via their own config). Value is in seconds.
export const maxDuration = 800

export async function POST(request: Request) {
  return Response.json({ ok: true })
}

For other frameworks and runtimes — Next.js < 13.5, Rust, Go, Python, Ruby — use vercel.json:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "functions": {
    "api/long-task.py": { "maxDuration": 1800 }
  }
}

Glob order matters, and Next.js projects using src/ must prefix paths with src/. For Python frameworks, key on the resolved entrypoint (app/main.py), not an /api route.

To change the project-wide default: Settings → Functions → Function Max Duration.

Pro and Enterprise teams can run individual functions for up to 1800s. Requirements, all of which are load-bearing:

• Per-function configuration only. Durations above 800s must be set in code or in vercel.json for that function. Project-level defaults above 800s are not supported during the beta — raising the dashboard default will not get you to 1800s.
• Supported runtimes only: nodejs20.x, nodejs22.x, nodejs24.x, Bun 1.x and 1.4.x, python3.12, python3.13, python3.14.
• Fluid Compute must be enabled (default for new projects).
• Secure Compute and Static IPs do not support durations above 800s during the beta. If the project uses either, you are capped at 800s.

// app/api/long-task/route.ts
export const maxDuration = 1800 // 30 minutes

export async function POST(request: Request) {
  await doTheLongThing()
  return Response.json({ ok: true })
}

Over HTTP/2, Vercel sends connection-level PING frames while the response is idle. HTTP/1.1 has no equivalent, so HTTP/1.1 clients and intermediate proxies may still close an idle connection long before 30 minutes elapse. For any long-running handler, stream progress or heartbeat data while the work runs rather than going silent and emitting one payload at the end.

Use getDeadline() to find out how much time is actually left and bail out cleanly:

import { getDeadline } from '@vercel/functions'

const deadline = getDeadline() // Date | undefined (undefined outside the Vercel Functions runtime)
const msRemaining = deadline ? deadline.getTime() - Date.now() : Infinity

Active CPU pricing is what makes this viable: a 25-minute function that spends 24 minutes awaiting an LLM bills almost no Active CPU, only Provisioned Memory for the instance while the request is in flight.

Do not chain functions, self-invoke, or poll to fake durability. Use Vercel Workflow, which pauses, resumes, and keeps state for minutes to months with no duration limit, plus automatic retries and crash safety. Rough guide:

• ≤ 300s → any plan, no configuration needed
• 300–800s → Pro/Enterprise, set maxDuration
• 800–1800s → Pro/Enterprise, extended-duration beta, per-function config
• Beyond 30 min, or needs to survive a crash/deploy → Vercel Workflow (workflow skill)

Workflow steps themselves support extended function durations, so a single step can also run up to 30 minutes.

Blowing the limit fails the build with Serverless Function has exceeded the unzipped maximum size of 250 MB.

Large functions raise the uncompressed bundle ceiling to 5 GB. This is what makes Python data/AI libraries, model weights, browser automation (Playwright/Puppeteer), image/video processing, and big backend apps deployable as Functions.

• Runtimes: Node.js, Bun, Python.
• Requires Fluid Compute with Active CPU enabled (default for new projects).
• New projects are eligible by default. Existing projects opt in with the VERCEL_SUPPORT_LARGE_FUNCTIONS environment variable, then redeploy:

vercel env add VERCEL_SUPPORT_LARGE_FUNCTIONS   # value: 1  (use 0 to disable)

The environment variable always takes precedence over the project default, in both directions.

• Only functions that exceed the standard limit use the large-function path — everything under 250 MB keeps the normal, faster path, so enabling it is not a global performance trade.
• Not supported with Secure Compute or Static IPs.

A 5 GB function still costs you cold-start time. Trim before you opt in:

In vercel.json (not supported in Next.js — see below):

{
  "functions": {
    "api/**/*.py": {
      "excludeFiles": "{tests/**,__tests__/**,**/*.test.py,fixtures/**,testdata/**}"
    }
  }
}

• Next.js ignores includeFiles/excludeFiles — use outputFileTracingIncludes / outputFileTracingExcludes in next.config.js instead.
• Audit heavy imports, prefer dynamic import(), and check for a package in dependencies that belongs in devDependencies.

Bundle size is not payload size. The request or response body of a Function is capped at 4.5 MB; exceeding it returns 413 FUNCTION_PAYLOAD_TOO_LARGE. For larger data:

• Uploads → Vercel Blob client uploads, which send the file browser → Blob directly, bypassing the function
• Large responses → stream them; streamed responses are not subject to the limit
• Otherwise, chunk across multiple requests

Create Dockerfile.vercel (or Containerfile.vercel) at the project root. Vercel detects it automatically and adds a rewrite routing all traffic to the image.

# Dockerfile.vercel
FROM node:26-alpine

RUN npm i -g srvx
WORKDIR /app
COPY server.ts .

# srvx listens on $PORT by default
CMD ["srvx", "--prod"]

// server.ts
export default {
  fetch(req: Request) {
    return Response.json({ ip: req.headers.get('x-forwarded-for') })
  },
}

Deploy with vercel deploy or a Git push. During the build, the image is built and pushed to Vercel Container Registry (VCR).

• Serve HTTP on port 80, or override with the PORT environment variable in project settings. A container that doesn't listen gets no traffic.
• Containers must be stateless. Each instance takes a request, returns a response, and keeps nothing between calls — that is what allows autoscaling and scale-to-zero. Persist to a Marketplace database, Redis, or Blob; never to the container filesystem.
• Scale to zero after 5 minutes without traffic in production, 30 seconds in preview. Cold starts are real; do not assume a warm process.
• SIGTERM with a 30-second grace period on scale-down (regular functions get 500 ms). Use it to drain.
• Logs are not per-request. stdout/stderr are broadcast to all inflight requests of the instance, so correlate with your own request IDs.
• Same Function limits and Active CPU pricing apply for size, memory, and duration.
• Secure Compute and Static IPs are not supported with custom container images. If you need either, deploy that part without a container.
• Local dev: vercel dev runs the image and requires the docker CLI plus a running daemon.

Use Services to deploy several frontends/backends in one project, containerized or not. Set runtime: "container" on any service you want built as an image; entrypoint points at the Dockerfile relative to that service's root.

{
  "services": {
    "frontend": { "runtime": "container", "root": "frontend/", "entrypoint": "Dockerfile.vercel" },
    "backend":  { "runtime": "container", "root": "backend/",  "entrypoint": "Dockerfile.vercel" }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "backend" } },
    { "source": "/(.*)",     "destination": { "service": "frontend" } }
  ]
}

Services are internal by default — without a top-level rewrite, nothing is publicly routable. When services is present, build/runtime keys (functions, buildCommand, installCommand, outputDirectory, framework) move into the service and are no longer valid at the top level.

vercel vcr login docker              # authenticate Docker with a short-lived OIDC token
vercel vcr image ls my-app           # list images
vercel vcr image inspect my-app <id>
vercel vcr image rm my-app <id>

Registry limits: 2 GB per compressed layer, 15 GB total image size, 4 MB manifest, 1 MB config blob. Layers must be gzip or zstd compressed — uncompressed OCI layers are rejected. Repositories per project: 10 (Hobby) / 1,000 (Pro) / 5,000 (Enterprise). Storage is billed at $0.10 per GB.

Good fits: Go, Rust, Ruby, PHP, or other backends; apps needing system libraries like FFmpeg or Chromium; frameworks outside Vercel's auto-detection; guaranteed build/runtime parity across environments.

Poor fits: anything that must hold state in-process, keep a daemon alive between requests, or run background work independent of a request. Reach for Workflow, Queues, or Cron for those.

If your framework is already auto-detected and you have no system-library needs, the standard build is simpler and faster — a Dockerfile is not an upgrade by default.

Hobby function limits went up substantially with Fluid Compute, and stale 10s/60s numbers are a common source of bad advice:

• Duration: 60s → 300s for both the default and the maximum — a 5× increase. Hobby functions can run a full five minutes.
• CPU: the Basic instance was removed; Hobby now runs Standard, 1 vCPU / 2 GB (up from 1 vCPU / 1.7 GB), managed by Vercel with a minimum of 1 vCPU.
• Hobby still cannot configure memory/CPU, use the extended 30-minute duration, or run in multiple regions — those remain Pro/Enterprise.

WebSockets work like any distributed WebSocket server — export an http.Server and use a library such as ws:

// api/ws.ts
import http from 'http'
import { WebSocketServer } from 'ws'

const server = http.createServer()
const wss = new WebSocketServer({ server })

wss.on('connection', (ws) => {
  ws.on('message', (data) => ws.send(data)) // echo
})

export default server

Higher-level realtime libraries like Socket.IO work too. Configure the client to use the WebSocket transport directly — Socket.IO defaults to HTTP long-polling, which won't work:

// api/socket-io.ts
import http from 'http'
import { Server } from 'socket.io'

const server = http.createServer()
const io = new Server(server)

io.on('connection', (socket) => {
  socket.on('message', (data) => socket.send(data))
})

export default server

// client.ts
import { io } from 'socket.io-client'

const socket = io('https://your-domain.com', {
  // Socket.IO appends /socket.io, so the full path becomes /api/socket-io/socket.io
  path: '/api/socket-io/socket.io',
  transports: ['websocket'], // required — Socket.IO defaults to HTTP long-polling
})

Express, Hono, and Nitro (including Nuxt, via native WebSocket support) serve WebSockets the same way — export the HTTP server. Python frameworks work too: FastAPI handles the upgrade natively, and python-socketio is protocol-compatible with the JS Socket.IO client.

Next.js doesn't expose an API for handling WebSocket upgrades. Use experimental_upgradeWebSocket() from @vercel/functions inside a route handler:

// app/api/ws/route.ts
import { experimental_upgradeWebSocket, type WebSocketData } from '@vercel/functions'

export async function GET() {
  return experimental_upgradeWebSocket((ws) => {
    ws.on('message', (data: WebSocketData) => ws.send(data))
  })
}

• Connections close when the function reaches its max duration. Clients must reconnect with backoff, then resubscribe to channels and reload any state they need.
• No instance affinity across connections. A reconnect — or a new deployment — may land on a different instance, so never keep durable state, presence, rooms, or pub/sub coordination in memory. Use an external store such as Redis from the Marketplace.

// client.ts — reconnect with exponential backoff
let socket: WebSocket
let delay = 1000

function connect() {
  socket = new WebSocket('wss://your-domain.com/api/ws')
  socket.addEventListener('open', () => { delay = 1000 })
  socket.addEventListener('message', (e) => console.log(e.data))
  socket.addEventListener('close', () => {
    setTimeout(connect, delay)
    delay = Math.min(delay * 2, 30000)
  })
}

connect()