Bun 1.3 launches a unified, batteries-included full-stack JavaScript runtime—here’s how to use it now

Bun 1.3’s release cuts through the noisy landscape of full-stack JavaScript runtimes by nailing both speed and built-in scope, and this is not just busywork. It’s possible now—for the first time—to run, build, test, install, bundle, serve, and even manage backend database connections, all using the same tool and language, with no wrappers or polyfills. Their focus on startup time (sub-30ms for even full web apps) and tight native integrations enables the kind of end-to-end workflow JavaScript engineers have wanted for a decade. With a single runtime and a unified CLI, local dev, CI, and prod become a single rational DAG, letting you build faster and ship smaller.

Why Bun 1.3 sets a new standard for full-stack JavaScript runtimes

Bun 1.3 pushes clear air into the full-stack JavaScript ecosystem. It bundles not just a high-performance runtime with a JavaScriptCore backend, but also native tooling for tasks that, historically, demanded a grab bag of slow and noisy dependencies. Cold boot times for even loaded projects hover below 30ms—a direct result of skipping “node_modules” overhead and using their own ultra-fast linker. In the typical DX gridlock, you’re dealing with Node, npm, webpack, jest, and a parade of lints/spinners just to run a simple stack. Bun collapses this. You get:

• The full runtime and dev toolkit in one binary
• Hot reloads that actually deliver on the “save, see, tweak, see” loop, <20ms in real stacks
• Native TypeScript “everywhere” (runner, repl, bundler) with no explicit build step
• Zero-jank environment startup (no “node_modules” scans, no lockfile waits)

Bun’s real kicker—and what makes this release worth noting for production—is its focus on "raw millisecond" developer cycles and the willingness to ship batteries-included. That’s a philosophical break from the “everything is a module” world, and it puts pressure not just on legacy Node stacks but also on frameworks like Deno.

If you’re building services or apps and want setup to reflect production as closely as possible, this version actually delivers.

Exploring Bun 1.3’s built-in developer tooling

Bun isn’t just a runtime; it’s now fully loaded with tools you’d typically bolt together with four or five npm packages—except faster and working out-of-the-box. With 1.3, you get a test runner, a REPL, a bundler, and a package manager all in the same CLI surface. No polyfills, no wrappers; just literal one-call commands.

For example, spinning up tests is as tight as:

bun test

This command detects and runs all your project’s tests, recognizes .test.{js,ts} and .spec.{js,ts} patterns, and uses bun’s own runner. It outpaces Jest/Node by a visible margin—sub-10ms cold for non-trivial suites.

TypeScript isn’t an afterthought either. You can run and debug TypeScript directly no tsc needed:

bun run src/app.ts

The integrated REPL is also built for rapid exploration. Start a Bun-flavored shell with:

bun repl

TypeScript input works natively, and you have Bun APIs in scope—no import dance required.

Beyond test/dev loops, Bun leans into production workflows. The bundler understands imports, exports, and even common Node APIs, producing single-file outputs with correct shims. Serving built assets or static sites is just:

bun bun ./dist

No dedicated “serve” package needed.

What this does for teams: your startup time for a clean checkout drops under ten seconds, and your local/prod parity gets sharper. By bundling tools natively, Bun 1.3 reduces cognitive overhead and dependency sprawl, which translates directly to bug surface and CI time.

Takeaway: with one CLI, real cold < 30ms tool spins, and zero config, Bun 1.3’s internal tools are production-useful and actually ready to replace your Node/tsc/webpack pipeline.

Unified database clients and APIs: simplifying backend integration

Bun 1.3 introduces built-in, native database clients for both PostgreSQL and MySQL, collapsing the usual tangle of client libraries, wrappers, and ORM glue. These are not polyfilled Node modules—they’re native implementations that talk directly to the database, giving you real performance and better error fidelity.

To set up a PostgreSQL connection:

import { Client } from "bun:postgres";

const client = new Client({
  connectionString: "postgres://user:pass@localhost:5432/mydb"
});
await client.connect();

const res = await client.query("SELECT * FROM users");
console.log(res.rows);

For MySQL, the shape is just as direct:

import { createConnection } from "bun:mysql";

const connection = createConnection({
  host: "localhost",
  user: "me",
  password: "secret",
  database: "mydb",
});
const [rows, fields] = await connection.query("SELECT * FROM users");

No node-gyp, no native module build step, no 30s npm install. This approach does two things fast:

1. It slashes integration time for new backends—straight to the query without glue
2. It ensures your test, dev, and prod environments are consistent to the wire protocol

The takeaway: Bun’s database API is both simpler and closer to the metal than most “everything to everyone” ORMs, with listed-first-party support for the most common production DBs. This is a time save and an environment flattener.

Production builds and standalone executables: ship with confidence

A big sell for Bun 1.3 is it finally closes the gap between prototyping and production deliverables, not just with sub-100ms builds but also with native standalone executables. The “bun build” tool, added in 1.3, bundles full JavaScript/TypeScript projects—dependencies, assets, and all—down to a single binary or directory. That means real no-dependency deploys.

Build a standalone executable with:

bun build src/main.ts --compile --outfile=dist/app

This produces a binary you can copy, ship, or run anywhere Bun itself can run (Linux x64/ARM, macOS, Windows listed as “work in progress”). The bundler respects .ts, .js, and even linked assets, all with hot reloading preserved in dev mode.

For static assets, serve with:

bun bun ./dist

Production builds follow the same code path as development—a deliberate design choice to avoid the “works in dev, fails in prod” trap that hits so many Node/webpack ecosystems.

A major deploy error class—“wrong node_modules,” missed asset copying, mismatched bundler flags—drops out of your workflow. And because “bun build” is in the core, you get consistent outputs whether on your laptop or in a CI runner.

Takeaway: with full native builds and single-executable output, Bun 1.3 makes both staging and shipping to prod smaller, more reliable, and actually testable—close to Go’s ideal, in the JavaScript world.

How to get started with Bun 1.3 today

Zero install friction is a theme, and Bun 1.3 hits it. Getting going is a one-liner:

curl -fsSL https://bun.sh/install | bash

Windows is not GA but is “available for early feedback”—install with the same approach using Windows Subsystem for Linux.

To kickstart a new project:

bun create next ./my-next-app
cd my-next-app
bun install
bun dev

This spins up an opinionated Next.js clone, with first-hit hot reload and full asset serving—no Node runtime required.

Need testing? No extra packages:

bun test

Database? As above, import from "bun:postgres" or "bun:mysql" directly—no need to check npm or chase version glue. And because you have a REPL, any API surface is explorable in seconds:

bun repl
> import { Client } from "bun:postgres";
> // Connect, run ad-hoc queries live

To build for production or ship to CI:

bun build src/index.ts --compile --outfile=dist/app

Deploy is now “copy the binary.” This “converged surface” makes Bun approachable even for legacy Node/TypeScript teams—just swap out your start/build scripts and point to bun.

For everyday JS/TS teams stuck in slow Node/webpack/tsc land, this is several hours per week, per engineer, given back by faster builds and fewer breakpoints.

Positioning Bun alongside OTF SDK/kits

As devtools race forward, solid foundations become more, not less, essential. Bun 1.3 is a generational win for build and tooling ergonomics, and if you’re rolling prototyped endpoints, apps, or infra scripts, there’s no reason not to start there and iterate quickly. But the real backend—where state, secrets, and compliance glue live—benefits from more than just fast loops. That’s where the OTF kit layer fits: key management, cross-runtime portability, and durable neutral APIs that don’t change when your runtime does.

In practice: build and shape in Bun, especially when the spec is moving fast or DX friction slows the team. When it becomes time to anchor the persistent parts (infrastructure config, user state, audit trails), drop the persistent logic behind your OTF layers, and let the SDK own stability while Bun iterates the surface. That way, you’re out of “lock-in" territory—and when the next runtime makes a move, you move with it, not against it.

Bun will keep pushing the surface area, but the foundations underneath—OTF as a pluggable anchor, with Bun as a DX supercharger—mean your code, ops, and compliance layers march at different paces, and that’s long-term use.

Bun 1.3 is real progress: faster, more integrated, and more production-ready than most full-stack JS setups on offer. It earns a spot in the kit for anyone serious about cutting deploy time and developer wait loops, especially when paired intelligently with tools that make stability a layer, not a monolith.

(For full details, see the official Bun 1.3 release notes.)