Vercel now auto-detects Express and Fastify entry points and runs the whole app as one Fluid Compute Function, so teams can lift existing Node servers without writing a framework adapter. The catch is that routing, static files, and bundle size are still governed by Function limits: express.static is ignored, public/** is required, and the standard bundle cap is 250 MB.
What changed: zero-config Express and Fastify land on Vercel
Vercel added zero-configuration support for Express and Fastify, putting the two most widely used Node server frameworks on the same deployment track that Hono and NestJS already occupy. An Express app that exports its app or calls app.listen() can deploy without a vercel.json adapter or a separate build target. Fastify works the same way, with matching entrypoint conventions and the same single-Function runtime model. Both are documented in Vercel’s backend framework guides for Express and Fastify.
This is a shift in platform positioning. Vercel started as a frontend host with optional serverless functions; explicit adapters turned Node servers into something Vercel could run. Now the platform treats a Node server as just another entry point it recognizes, the same way it recognizes Next.js or SvelteKit. For teams with existing Express APIs or Fastify services, the practical effect is that migration no longer begins with “rewrite for serverless.”
The timing follows two earlier zero-config announcements: Hono on August 1, 2025, and NestJS on October 17, 2025, per Vercel’s community post and changelog. Express and Fastify are the larger population, so the pattern is no longer experimental.
How does zero-config deployment work?
Vercel looks for a recognizable entry file. For Express, valid names are app.{js,cjs,mjs,ts,cts,mts}, index.{...}, server.{...}, or the same names under src/. The file must either default-export the app or use the familiar app.listen() pattern. Fastify uses the same convention. When detected, Vercel bundles the entire app into a single Vercel Function and runs it on Fluid compute by default.
Fluid compute is Vercel’s longer-lived function runtime. Standard Vercel Functions spin up per request and default to the iad1 region near Washington, D.C. for Node.js workloads, though a project can pin functions to a region closer to its data source, according to the Functions documentation. Fluid compute keeps the function warm between requests, which matters for Express and Fastify because both frameworks expect a persistent process. Cold starts are not eliminated, but the runtime behavior is closer to a traditional Node server than a pure request/response lambda.
There are minimum CLI versions. Fastify requires Vercel CLI 48.6.0 or later, and Express requires CLI 47.0.5 or later. If your CI pipeline pins an older CLI, the detection step may not fire.
What’s the catch with the single-Function model?
“Zero config” applies to detection and bundling, not to runtime semantics. The whole application becomes one function. That means one bundle, one memory allocation, one regional placement, and one concurrency ceiling. If your Express app is actually a monolith with dozens of routes, all of them travel together.
The standard bundled function size limit is 250 MB, with Large Functions supporting up to 5 GB on Fluid compute in public beta, according to the Express guide. For a minimal API, 250 MB is plenty. For an app that pulls in native dependencies, machine-learning libraries, or a large node_modules tree, the cap is a real constraint. Teams that previously split a large app into multiple functions may find themselves back at a single deployment unit.
Routing is another gotcha. Vercel’s edge network handles routing before the function sees a request. Express routers still work inside the function, but the host is doing its own path matching and rewrite logic. Behavior that depends on Vercel-specific headers or rewrites may differ from a self-hosted Node server.
Where do static assets and error handling go wrong?
Static assets are the sharpest edge. express.static() is ignored on Vercel. Files must be placed in public/** to be served by the platform. If your existing Express app relies on app.use(express.static('dist')) or similar, it will build and deploy, but those assets will return 404s. This is documented explicitly in the Express on Vercel guide, and it is the kind of detail that gets buried until production traffic hits it.
Error handling is the other lifecycle trap. Express can swallow errors in a way that leaves the function in an undefined state and prevents Vercel from discarding and resetting it, per the same guide. Robust error handling is not a best-practice checkbox here; it is required for the function to recover correctly. A missed next(err) or an unhandled promise inside middleware can turn a single bug into a warm function that stays broken across multiple requests.
Fastify’s default error handling is more structured, but the same single-Function constraints apply. Any uncaught exception or unhandled rejection can poison the runtime. Builders should treat the function as a long-lived process that must stay clean, not as a stateless shell.
How does this compare to Hono and NestJS?
Hono and NestJS got the same zero-config treatment first. The unifying pattern is that Vercel detects a framework-shaped entry file, bundles it into one Function, and runs it on Fluid compute. The difference is the baggage each framework carries.
Hono is small and routing-first; its zero-config story is almost a perfect fit for a single function. NestJS is larger and more modular, but its architecture already separates controllers and providers, so collapsing it into one function is awkward but predictable. Express and Fastify are the ones with the most existing production code, the most varied middleware ecosystems, and the most assumptions about long-running processes and static file serving.
One signal that real-world reliability needs scrutiny: community reports around Hono zero-config builds breaking with relative imports. If the smallest of the four frameworks hit path-resolution issues, larger codebases should expect edge cases. The Hono announcement thread is the closest public tracker for that class of problem.
Who should use it, and when should you keep an adapter?
Use zero-config when your app is a straightforward API or small service with no custom static-asset routing and no need to split endpoints across multiple functions. It is the fastest path from a working Express or Fastify repo to a Vercel URL.
Keep a custom adapter, multiple functions, or another platform when any of the following are true: the bundle is near or above 250 MB; you rely on express.static() or equivalent for dynamic asset paths; you need different regions or concurrency settings for different endpoints; or your error-handling surface area is large enough that a single shared runtime is risky.
The platform is clearly moving toward making Node servers first-class citizens. That is useful. It does not make Node servers serverless-native. The limits are still Vercel Function limits, and zero configuration does not mean zero constraints.
Frequently Asked Questions
Which Vercel CLI versions does zero-config Express or Fastify require?
Express needs Vercel CLI 47.0.5 or later, while Fastify needs 48.6.0 or later. A CI pipeline or global install pinned below those versions will silently skip auto-detection and may fall back to a static build or a manual adapter. Check vercel --version before migrating an existing repo.
How does a zero-config Vercel deploy differ from running Express on a VPS?
The whole app becomes one Vercel Function with a 250 MB standard bundle limit, or up to 5 GB if you opt into the Large Functions public beta. Vercel’s edge routes requests before they reach Express, static files must live in public/**, and the Node.js default region is iad1 unless you override it. A VPS gives you a persistent process, no bundle cap, and full control over static-asset routing.
What repo layout changes should an Express team make before the first zero-config deploy?
Rename the entry file to app.{js,cjs,mjs,ts,cts,mts}, index.{…}, or server.{…}, or place it under src/; move static assets to a public/ folder at the project root, not nested inside the server directory; and remove or guard express.static() calls, because Vercel ignores them. Also add an explicit error boundary at the top of your middleware stack so uncaught errors do not keep the warm function in a broken state.
What failure mode from the earlier Hono launch could hit Express or Fastify codebases?
Community reports showed zero-config Hono builds breaking when relative import paths were resolved by Vercel’s bundler. Express and Fastify projects with sprawling relative imports, monorepo aliases, or native binary dependencies are more exposed to the same class of resolution and bundling failures, and their larger node_modules trees are more likely to brush against the 250 MB size cap.
When is it safer to stay with a custom adapter instead of using zero-config?
Stay with an adapter or multiple functions when you need different regions, concurrency, or memory per endpoint, when dynamic static-asset paths are required, or when the bundle is near 250 MB. Large Functions can lift the cap to 5 GB, but it is a public beta feature that must be enabled explicitly, so teams with strict production SLAs may prefer to split the app rather than depend on it.
