Bun runtime on Vercel Functions

Bun joins Vercel Functions as a public beta runtime

Vercel has added Bun as an available runtime for Vercel Functions, now in Public Beta alongside the existing Node.js option. Developers can select the runtime per project, matching execution behavior to workload type: Node.js for broad ecosystem compatibility, or Bun for compute-heavy tasks where reduced latency matters.

According to Vercel’s internal testing, Bun cut average latency by 28% in CPU-bound Next.js rendering workloads compared to Node.js. The gains are attributed to Bun’s runtime, built in Zig with optimized I/O and scheduling that lowers overhead in JavaScript execution and data handling.

Switching runtimes

Bun is currently supported for Next.js, Express, Hono, and Nitro, with more frameworks expected. Enabling Bun for an entire project is a configuration change in vercel.json:

{
  "bunVersion": "1.x"
}

This config applies Bun across all deployments and works with Vercel’s existing observability, logging, and monitoring tooling. Bun supports TypeScript with no extra setup, as shown in a simple Hono API:

import { Hono } from 'hono';
const app = new Hono();
app.get('/', (c) => {
  return c.text(`Hello from Hono on Bun ${process.versions.bun}!`);
});
export default app;

Starter templates are available for Express on Bun and Hono on Bun.

The Bun runtime runs on Vercel’s Fluid compute, which handles concurrent requests per instance. With Active CPU pricing, billing tracks time spent executing code, not full wall-clock time, so waits on database queries or API responses are not charged.

Benchmarking and what the numbers show

Independent developer Theo Browne published benchmarks comparing Cloudflare Workers and Vercel Functions across server-side rendering frameworks (Next.js, React, SvelteKit) and computational workloads. In follow-up analysis, Vercel profiled its infrastructure to identify bottlenecks.

The benchmarks initially measured time-to-first-byte (TTFB), which records when the server starts responding, not the full rendering and transmission cost. They were later updated to time-to-last-byte (TTLB), a more complete measure for server rendering workloads since it includes all rendering and streaming work.

Tests ran on Vercel with 1 vCPU/2GB in iad1 (us-east-1), with the benchmark client running in a VM in the same AWS region to limit network variance. Most request time was spent inside the application runtime; platform overhead was minimal.

Profiling revealed Node.js’s main bottleneck was its Web Streams implementation and transform operations, where buffer scanning and data conversions increased CPU usage. Garbage collection also consumed meaningful processing time under load.

For Next.js workloads, Bun reduced latency by 28% versus Node.js. React SSR, SvelteKit, and vanilla JavaScript benchmarks were similar across platforms. The Next.js improvement comes from Bun’s optimized web streams handling and lower garbage collection overhead. Vercel expects React SSR numbers to improve once it integrates Bun’s optimized react-dom/server implementation.

Strengths and tradeoffs

Each runtime has different advantages. Bun offers faster server rendering, while Node.js remains the most compatible and battle-tested option. The comparison table summarizes the differences:

Before shifting production traffic, test dependencies under Bun, as its Node.js API implementation may differ in some edge cases.

The Bun runtime for Vercel Functions is available in Public Beta, with work ongoing to expand framework support and optimize performance across both runtimes.