Vercel

Vercel has two standalone places you can mount a DaloyJS REST API handler, Node.js Functions and Edge Functions. Each target expects a slightly different export shape; the underlying app object is identical.

One app, two Vercel targets

identical appYour DaloyJS Appimport { app } from '../src/server.ts'

node.js runtimeNode.js Functionexport default toFetchHandler(app)

edge runtimeEdge Functionexport const runtime = 'edge' · toWebHandler(app)

Both shapes live at api/index.ts and need the /(.*) → /api rewrite so DaloyJS owns routing at the site root. Only the export shape and runtime differ; the app object is the same.

When to choose Vercel

You want a standalone DaloyJS REST API on Vercel Functions.
You want Fluid compute (the default since 2025) with per-request billing.
You want preview deployments per PR with zero CI config.

Scaffold

The Vercel starter scaffolds a standalone REST API on the Node.js runtime (the toFetchHandler entrypoint shown below), which Vercel now recommends for standalone functions. The old vercel template name still works as a deprecated alias.

bash

pnpm create daloy@latest my-api --template vercel
cd my-api
pnpm vercel dev

1. Vercel Node.js Functions (standalone API)

For a standalone DaloyJS REST API on the Node.js runtime, use a single function at api/index.ts. Vercel Node.js Functions expect a default export with a fetch method.

// api/index.ts
import { toFetchHandler } from "@daloyjs/core/vercel";
import { app } from "../src/server.ts";

// Node.js is the default runtime. No runtime export needed.
export default toFetchHandler(app);

Vercel maps api/index.ts to /api, but a DaloyJS app registers its routes at the root (/healthz, /docs, …). Add a rewrite so every path reaches the function and DaloyJS owns routing at the site root, without it the deployed root domain returns a Vercel 404:

json

// vercel.json
{
  "rewrites": [{ "source": "/(.*)", "destination": "/api" }]
}

2. Edge runtime opt-in (deprecated by Vercel)

// api/index.ts
import { toWebHandler } from "@daloyjs/core/vercel";
import { app } from "../src/server.ts";

export const runtime = "edge";
export default toWebHandler(app);

The same /(.*) → /api rewrite applies. Vercel has deprecated standalone Edge Functions, so prefer the Node.js runtime in section 1; reach for this opt-in only for an existing Edge workload. The Edge runtime uses the web-standard toWebHandler and its code must avoid node: modules.

vercel.json

The rewrites rule above is required for root routing. Add functions for per-function memory/duration limits, and regions to pin a region:

json

{
  "rewrites": [{ "source": "/(.*)", "destination": "/api" }],
  "functions": {
    "api/index.ts": { "memory": 1024, "maxDuration": 30 }
  },
  "regions": ["fra1"]
}

The legacy builds property is deprecated, use functions instead.

Deploy

bash

# preview
pnpm vercel deploy

# production
pnpm vercel deploy --prod

# env vars (encrypted)
pnpm vercel env add SESSION_SECRET production

Storage

Vercel KV and Vercel Postgres no longer exist as Vercel-owned products. They were sunset in December 2024 and existing stores were migrated automatically, Vercel KV to Upstash Redis, Vercel Postgres to Neon. For new projects, add the equivalent integration from the Vercel Marketplace (Neon for Postgres, Upstash for Redis), the integration provisions the store and injects the connection env vars into your project.

Vercel Blob and Edge Config are still first-party Vercel products. See Neon for the Postgres setup and distributed rate-limit store for the Redis setup.

Gotchas

Edge runtime has no node:*: keep middleware portable, and prefer fetch-based drivers (Neon serverless, PlanetScale, Turso) when running on Edge.
Standalone Vercel Node functions want a default export with { fetch }. Use toFetchHandler.
Vercel sets process.envon Node functions; on Edge, secrets are bundled at build time, so don't read them outside the handler.

Search docs