next-bun-compile

Why next-bun-compile?

One binary, ship anywhere

next build produces a single ./server executable with every static asset, public file, and runtime chunk embedded. Copy it to a distroless image, scp it to a VM, attach it to a release — that’s the deploy.

Memory-served hot paths

Static assets and fully-static prerendered pages are served straight from memory; ISR pages get an invalidation-aware in-memory cache. First byte in ~60ms — Next.js boots lazily on the first dynamic request.

Smaller image footprint

~30MB binary on distroless beats ~150MB for bun + standalone setups. For native deps like sharp, the runner adds the C runtime libs and you’re at ~80MB total.

Native deps just work

sharp, bcrypt, better-sqlite3 — handled. A runtime resolver hook

• build-time chunk rewrite makes externalized packages resolve cleanly from inside the compiled binary, with no per-package configuration.

Monorepo aware

Bun workspaces, pnpm workspaces, Turborepo all work. The standalone trace’s nested layout (standalone/apps/web/server.js) is handled correctly out of the box.

Works with what you already use

One line in your next.config.ts (adapterPath: "next-bun-compile"). No changes to your app code, no opinions about your routing or data layer.

Quick start

bun add -D next-bun-compile

next.config.ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  adapterPath: "next-bun-compile",
};

export default nextConfig;

next build    # → ./server, one command
./server      # serves on port 3000

Full walkthrough in Getting Started.