Bun in 2026: Ship Your Greenfield SaaS, Skip the Migration

TL;DR: Bun is ready to run a greenfield SaaS backend in 2026. Start new projects on Bun 1.3+ with Elysia and Drizzle, and size containers for a bigger memory footprint than Node (oven-sh/bun #17723). Skip migrating a working Node backend: 91% of State of JS respondents still run Node, and migrations capture the least of Bun's upside.

Is Bun ready to run your SaaS backend in 2026? For a greenfield build, yes; for migrating a working Node.js backend, no. Pick Bun on day one of a new project and its advantages cost nothing; drag an existing service onto it and you pay a compatibility long-tail for gains a new codebase collects for free. That split verdict comes from ShipKit, a SaaS boilerplate whose backend runs Elysia on Bun, and it is written for solo developers and technical founders choosing a stack for a new product.

July 2026 is why the question needs re-asking: Bun announced v1.4, a complete Zig-to-Rust core rewrite executed by parallel Claude agents, still canary-only while stable Bun holds at the Zig-based 1.3.x line, and the runtime's trust debate restarted mid-year. The adoption baseline stayed put through all of it. State of JS 2024 counts 16% of respondents using Bun while 91% still use Node.js, so the decision in front of you is narrower: should a brand-new backend collect Bun's built-in advantages while the incumbent keeps carrying the legacy apps?

What actually changed for Bun in 2025 and 2026?

Three dated events reset the question inside twelve months. Bun 1.3 (October 10, 2025) made the runtime batteries-included: PostgreSQL, MySQL and SQLite through Bun.SQL, a built-in Redis client, full-stack Bun.serve() routing. The Anthropic acquisition of Bun (December 3, 2025) kept the runtime MIT-licensed. Bun announced v1.4, the Zig-to-Rust rewrite, on July 8, 2026 (canary-only at launch).

Timeline of Bun 1.3 in October 2025, the Anthropic acquisition in December 2025 and the Zig-to-Rust v1.4 rewrite announced in July 2026, ending in the greenfield-yes verdict

Bun's twelve decisive months: batteries-included 1.3 in October 2025, the Anthropic acquisition keeping the MIT license in December 2025, and the v1.4 Rust rewrite announced in July 2026, canary-only at launch.

The 2023–2025 objections were specific: no batteries, a single VC-backed company as bus factor, a compatibility story full of workarounds. Bun 1.3 answered the first with 98%+ of Node's N-API tests passing; the acquisition answered the second, with development continuing publicly under MIT. What stays open is trust in the process behind v1.4. One scope note: Bun as a package manager, bundler or test runner is deliberately out of scope here, because those adoption paths are settled and low-risk; the contested bet is the runtime under a production API.

Can you trust Bun after the 11-day AI rewrite?

Can you trust Bun after the rewrite? The announced Bun v1.4.0 replaces the Zig core with Rust: a +1,009,272-line diff converting 1,448 Zig files, produced in 11 days by one engineer directing up to 64 parallel Claude agents, at roughly $165,000 in API cost. The verdict hangs on which evidence you weight: the unreviewable process, or the production record since.

The case against: a million lines nobody reviewed

Start with the strongest objection, raised in the Hacker News thread where yt-dlp marked its Bun support limited and deprecated:

If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it?

Practitioners in the same thread put the review math plainly: "It's simply not possible for a team that size to review that much code in that little time." Andrew Kelley, creator of Zig, called the result "unreviewed slop"; he is an interested party, since Bun just left his language, and his critique is pointed and personal (he has called Bun's pre-LLM code slop too), which is why the argument deserves the weight, not the tone. The objection lands because its core is true: no human team reviewed a million-line diff in eleven days, and the 19 known regressions v1.4 introduced (and later fixed) prove the test suite did not catch everything.

The case for: three weeks in production, and nobody noticed

Bun's own release numbers set the floor, labeled as self-reported: 100% of the test suite passing on all platforms before merge, 128 bugs fixed relative to v1.3.14, a binary about 20% smaller on Linux and Windows, 2–5% faster. The decisive datapoint is the production exposure: the Rust build ran inside Claude Code, a product Anthropic reports at a $1B annualized run rate, for three weeks before anyone publicly noticed. Simon Willison, reviewing the project independently, called it "an extremely sophisticated piece of agentic engineering". The shipped result, in the words of Bun's own release post (self-reported, like the numbers above):

Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.

Bun v1.4 Rust rewrite trust evidence: unreviewed million-line diff weighed against three weeks running inside Claude Code

Bun v1.4's trust question weighs an unreviewable 11-day process against three weeks of unnoticed production service inside Claude Code.

Tests verify behavior; review verifies intent. A million-line diff has the first without the second, which keeps the fear legitimate while draining it of decision weight: what a founder bets on is production exposure over time, and the Rust Bun banked three weeks of it inside a heavily used product before its own announcement. Pin the runtime like any dependency: lock the Bun version in CI and in your Dockerfile, and take major upgrades as deliberate deploys after the issue tracker has spoken, never on release day.

Will Bun blow past your container's memory limit?

Documented, yes, in oven-sh/bun #17723 and #25948. A service holding ~500MB on Node spiked to its ~1.2GB container limit on Bun after a two-line Dockerfile change (#17723, open since February 2025); #25948 (closed as a duplicate in May 2026, not fixed) documented idle growth under Mongoose: RSS creeping from 50MB to 170MB over 12 hours with no traffic.

The classic first mistake is exactly that swap: FROM node becomes FROM oven/bun on an existing service, memory limits stay untouched, and the change ships because everything works. The service stays responsive, the logs stay clean, and RSS climbs to the ceiling until the platform's OOM killer restarts the container. On Cloud Run, Fly.io or GKE the symptom that surfaces first is usually a rising restart count. The question teams then search, why is my Bun server using so much memory in Docker, has issue numbers for an answer.

As of July 2026 there is no confirmed root cause and no fix: #17723 stays open, and #25948 was closed as a duplicate rather than resolved. Connection-pool tuning does not stop the idle growth either: one production report set minPoolSize: 0 and maxIdleTimeMS and the leak continued; another shows process RSS creeping while the JS heap stays flat. Load-test verdicts belong to container RSS measured over hours, never to heap snapshots taken over minutes.

Do not copy Node memory limits into a Bun deploy: in the one documented like-for-like case, the same workload hit 2.4× its Node footprint before the container ceiling cut it off, so treat that multiple as a floor, not a measured peak. The delta decides real money on memory-priced platforms, which is why it belongs in the greenfield plan instead of a postmortem. Priced in, it is a line item: pick the container size with the delta included, soak-test for a working day, and alert on RSS. A failure mode documented down to the issue number is a manageable one.

Bun 1.3 replaces the npm picks a Node stack has to maintain

A greenfield Node backend opens with four decisions: a Postgres client, a Redis client, an HTTP framework, a deploy artifact. Bun 1.3 ships all four inside the runtime: Bun.SQL speaks PostgreSQL, MySQL and SQLite, the Redis client is built in, Bun.serve() routes full-stack, and one compile step emits a standalone executable.

Node stack npm picks pg, ioredis and Express versus Bun 1.3 built-ins Bun.SQL, Redis client, Bun.serve routing and standalone compile

Bun 1.3 replaces four third-party stack picks with runtime built-ins: Bun.SQL for PostgreSQL, MySQL and SQLite, a Redis client, Bun.serve() routing and standalone-executable builds.

Every third-party pick you skip is an upgrade cadence, a CVE feed and a maintainer risk you skip with it. For a solo developer that arithmetic decides whether the week goes to product code or to the dependency tree.

Elysia is the framework question the readiness checklists skip. TechEmpower Round 22 plaintext, run in late 2023 (Round 23 followed in March 2025), puts Elysia on Bun at 2,454,631 requests per second against 113,117 for Express on Node, the origin of Elysia's 21x-faster-than-Express line. Read a benchmark that old honestly: a runtime-plus-framework number on a synthetic workload, so a real SaaS API bound by Postgres and the network will see nothing like 21x. Elysia on Bun is good enough for a production API, and the reason to pick it is fit, not the benchmark: Bun-first design with end-to-end type inference. ShipKit's backend runs on exactly this pairing, Elysia with Drizzle (the architecture overview shows how the monorepo wires them), because those are the picks that survive Bun's compatibility surface without workarounds.

Two caveats that ambush you in week two

ORM first. Drizzle runs on Bun; Prisma was the long-standing blocker, and the complaint pattern was old and consistent: "I'd use it if it weren't for my wish to use Prisma on my project" summarized the compatibility long-tail on Hacker News back in 2023, and that long-tail is why Bun still advertises N-API pass rates as a headline metric. Prisma has since closed most of that gap and ships an official Bun guide today; Drizzle stays the pick here because it is the ORM ShipKit ships and tests on this stack. Debugging second. A February 2025 write-up on Bun 1.2.x found bun --inspect ignored breakpoints unless the process held a port listener (a condition a long-running API meets), with --inspect-brk and --inspect-wait failing outright; the live breakpoint issue today is narrower, oven-sh/bun #32591, where the inspector reports a top-level breakpoint before the previous line's declaration has initialised. Both caveats are day-one decisions on a greenfield project: pick your ORM before the first migration, keep log-first debugging as the default until the inspector's remaining edges close, and neither ambushes anyone. Call the general shape the greenfield asymmetry: a constraint you choose around before the first commit costs nothing, while the same constraint discovered under a working backend becomes a migration blocker.

Should you migrate an existing Node backend to Bun?

Rarely. Node.js in 2026 is no slow-moving target: it keeps absorbing Bun's headline advantages, built-in TypeScript execution among them, and 91% of State of JS 2024 respondents still run Node.js. A migration pays Bun's compatibility long-tail to capture gains a greenfield project collects for free.

The strongest migration story of 2026 arrives with its own correction. Trigger.dev rebuilt Firestarter, its warm-start connection broker, on Bun in March 2026 ("Firebun") and reports 5x throughput; the top Hacker News comments attribute much of the gain to swapping SQLite and Zod and to optimizations applied only to the Bun version. Both halves belong in your decision: the result is real, and the runtime is only part of the cause. The pattern generalizes, because a migration always bundles a rewrite, and the rewrite is usually where the speed hides.

When staying on Node is the right call

Staying on Node is a first-class outcome of this article, and for three concrete readers the correct one: a backend with paying customers and one dependency sitting in Bun's compatibility long-tail; a deploy shaped around AWS Lambda or Vercel functions, where the managed runtimes are Node; a team whose debugging workflow lives in breakpoints and cannot absorb inspector rough edges like #32591. A working Node backend in 2026 is not a problem to fix. The greenfield asymmetry runs the other way for your next product: a new codebase collects the built-ins, the one-file deploys and Elysia's type system at zero migration cost, which is why ShipKit ships its stack greenfield-first, an Elysia-on-Bun backend you start on rather than a migration target you drag a legacy app toward.

The expensive part of a greenfield Bun stack is the plumbing

A greenfield-yes verdict answers the runtime question and leaves the costlier half. Auth, billing, an admin panel, i18n, background jobs: that plumbing eats a month between an empty repo and a first paying customer, and ShipKit exists precisely for it. Bun saves you dependency picks; it does not build your OAuth flow.

ShipKit closes that gap on the exact stack this article endorses: fourteen production subsystems pre-wired in one Turborepo monorepo, spanning Better Auth (email, OAuth, magic link, RBAC), payments, an admin panel, i18n, background jobs, a webhook worker, feature flags, file storage and observability, across 7 apps, 17 packages and 68 UI components. The greenfield asymmetry is the whole reason the math works: nothing exists yet, so adopting a pre-wired codebase costs zero migration and returns the plumbing month. The price is $149 one-time for full source, unlimited projects and lifetime updates; there is no trial, so price the decision on the source access itself. Before writing the first line of auth code, price those fourteen subsystems against your own hourly rate; that arithmetic is the entire build-vs-buy decision.

Next step: the verdict was greenfield-on-Bun, so spend the saved month on product instead of plumbing.

Get ShipKit — $149 one-time · See the architecture

FAQ

What does the Anthropic acquisition mean for Bun's roadmap?

Bun remains MIT-licensed open source, with the team continuing development publicly on GitHub, which retired the 2023–2025 bus-factor objection. The open question is priority: the December 2025 announcement paired the acquisition with Claude Code's growth, so server-runtime features now share a roadmap with agent infrastructure. Watch the release notes; intent shows up there first.

Is the Rust build already the default Bun?

Not yet. Bun v1.4.0, announced July 8, 2026, is the Rust rewrite, and it ships only on the canary channel: bun upgrade --canary installs it, while a plain bun upgrade still delivers the Zig-based 1.3.x line (v1.3.14 at the time of writing). The Rust port did run inside Claude Code for weeks before the announcement, so its production exposure predates its stable release. Pages calling the build Linux-only are outdated, since the test suite passed on all platforms before merge; canary remains the accurate label until a stable v1.4.0 ships.

Should you pick Elysia or Hono for a Bun backend?

Elysia when the backend lives on Bun, Hono when portability matters. Elysia is Bun-first with end-to-end type inference; Hono targets many runtimes, including edge platforms like Cloudflare Workers. A containerized SaaS API committed to Bun gets more from Elysia's type system; a codebase that needs to move between runtimes keeps more options with Hono.

Can you run Bun on AWS Lambda or Vercel serverless?

Not on a managed runtime: Lambda and Vercel functions provide Node.js runtimes, and running Bun there means a custom runtime layer or a container image. Bun's natural deployment targets in 2026 are container platforms such as Fly.io, Cloud Run or Railway, where the memory sizing guidance from issue #17723 applies before you set limits.

What about Deno for a greenfield backend?

Deno is the third runtime on the same State of JS chart and a legitimate greenfield option: Deno 2 runs npm packages and ships its own toolchain. It optimizes for a different bet, TypeScript-first tooling and its own hosting platform in Deno Deploy, while this article's decision is a containerized Elysia-on-Bun API. If Deno's toolchain or hosting story fits your deploy, evaluate it on the same axes used here: built-ins, npm compatibility and memory behavior in your container.