Link to headingHow to use the Bun runtime

The Bun runtime is currently supported for Next.js, Express, Hono, and Nitro, with support for additional frameworks coming soon.

To enable Bun for your entire project, add the bunVersion setting to your vercel.json file:

This configuration applies Bun across your entire deployment and integrates with Vercel's observability, logging, and monitoring infrastructure automatically.

Bun supports TypeScript with zero configuration. Here's an example of creating a simple API with Hono:

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;

You can also get started by using one of our starter templates:

The Bun runtime runs on Fluid compute, which handles multiple concurrent requests on the same instance. Active CPU pricing means you pay for time spent executing code, not wall-clock time waiting on responses. If your function is waiting for a database query or an API call, you're not being charged for that wait time.

Link to headingWhy runtime choice matters

Applications handle different kinds of workloads. Some perform heavy computation, others handle high request volume or stream large responses. Choosing the right runtime for your application lets you optimize for what matters most.

Bun delivers low-latency performance, efficient streaming, and robust built-in APIs through a safety-focused systems language, while Node.js offers unparalleled ecosystem maturity and broad compatibility for every use case. The choice depends on your application's priorities.

Because Vercel runs native Node.js and Bun runtimes, code runs exactly as it does locally. No emulation or compatibility layers, just full access to each runtime's native capabilities. Switching between them is a configuration change in vercel.json.

Link to headingBenchmark results

Recently, independent developer Theo Browne published comprehensive benchmarks testing CPU performance across server-side rendering (Next.js, React, SvelteKit) and computational workloads, comparing Cloudflare Workers and Vercel Functions. We analyzed the results in our previous post.

We want to thank Theo for this work. Efforts like these surface valuable insights into runtime performance, and healthy competition helps push the entire ecosystem forward, benefiting everybody.

Following the initial benchmarks, improvements were made across the ecosystem. Cloudflare optimized their scheduling algorithm and V8 garbage collection tuning, and proposed a PR to Node.js enabling a V8 flag that improves math operations. Work on OpenNext improved Next.js performance across alternative hosting environments. We profiled our infrastructure and identified bottlenecks in Node.js web streams implementation.

Link to headingWhat we measured when profiling

The original benchmarks measured time-to-first-byte (TTFB), which captures when the server begins sending a response but not the full cost of generating and transmitting it. The benchmarks were updated to measure total request duration (time-to-last-byte). For server rendering workloads, this more accurately represents what users experience, as it includes the complete work of rendering and streaming the response.

We deployed to Vercel with 1 vCPU/2GB in iad1 (us-east-1) and ran the benchmark client from a VM in the same AWS region to minimize network variability.

The benchmarks focused on server-side rendering, the process of generating HTML from React components on the server before sending it to the browser. This differs from client-side rendering, where the browser receives JavaScript and builds the page itself.

Platform overhead is the time spent in infrastructure code before reaching your application. In these tests, platform overhead accounted for only a small fraction of total request time. Nearly all execution occurred inside the application runtime.

Profiling showed that the main bottleneck in Node.js came from its Web Streams implementation and transform operations, where buffer scanning and data conversions added measurable CPU cost. Garbage collection also consumed a significant share of total processing time under heavy load.

For Next.js workloads, Bun cut latency by 28% compared to Node.js. Performance was similar across platforms for React SSR, SvelteKit, and vanilla JavaScript benchmarks. The Next.js performance gains come from Bun's optimized handling of web streams and reduced garbage collection overhead. We expect the numbers for React SSR will improve further once we integrate Bun's optimized react-dom/server implementation.

The complete benchmark implementation is available on GitHub.

Link to headingPerformance characteristics and tradeoffs

Each runtime has distinct strengths. Bun delivers clear speed improvements for server rendering workloads, while Node.js remains the most compatible and battle-tested environment.

The table below summarizes their key differences:

Link to headingDeploy Bun on Vercel

The Bun runtime is now available in Public Beta.

We're continuing to expand framework support and optimize performance across both Node.js and Bun. If you hit performance issues or have benchmarks to share, we want to see them.