Elysia vs Hono — Bun-native server picks in 2026

Pick Hono if you’re deploying to Cloudflare Workers, need a framework that runs identically on Node.js, Deno, and Bun, or want the largest ecosystem and community. Pick Elysia if you’re on Bun exclusively and want Eden Treaty — an end-to-end type-safe RPC client with no code generation and zero schema duplication.

Who this is for

TypeScript developers choosing an HTTP framework for a Bun-based backend in 2026. If you’re still on Node.js with no migration path, this choice doesn’t affect you yet — Hono works well on Node.js but Elysia is Bun-first. If you’re evaluating whether to use Bun at all, start at Bun vs Node. If you’re considering Hono as a TypeScript-native replacement for Express, see Hono vs Express first.

What we compared

Elysia v1.4 (with CF Workers adapter) against Hono v4.12. We wrote equivalent endpoints in both frameworks to compare API shape, TypeScript ergonomics, and client generation. Benchmarks are not ours — raw numbers failed adversarial verification across every source we checked. For current throughput data, consult the bun-http-framework-benchmark directly. The qualitative performance picture: both frameworks are fast for Bun HTTP work. Neither is a bottleneck in practice.

Quick-pick table

Criterion	Elysia	Hono
Primary runtime	Bun	Bun, Node.js, Deno, CF Workers, Vercel Edge
Cloudflare Workers	Experimental (`CloudflareAdapter` + `.compile()`)	Production-ready, Cloudflare-endorsed
Type-safe client	Eden Treaty (no codegen, Bun-first)	`hc<AppType>()` (works cross-runtime)
GitHub stars (May 2026)	18,418	30,678
npm ecosystem / middleware	Smaller, Bun-native plugins	Larger, more third-party middleware
TypeScript inference speed	82% faster (self-reported, Elysia 1.0)	Improved post v4.10.0
Validation	Built-in (`t.*` via TypeBox)	Bring your own (Zod, Valibot, etc.)

Elysia

Elysia was built for Bun from the start. The programming model treats validation and type inference as one thing — you define your schema with t.* helpers (TypeBox under the hood), and TypeScript infers the handler’s input types from those definitions automatically. No separate .parse() call. No drift between runtime validation and compile-time types.

The headline feature is Eden Treaty: a client library that derives its API surface from your server type with treaty<typeof app>(url). You get autocompletion, typed request bodies, and typed responses without running a code generator or maintaining a separate schema file. If you’re building a monorepo where the frontend and backend share a package, this cuts a category of bugs entirely.

Elysia 1.3 shipped meaningful performance improvements. Route registration is ~2.7× faster with ~5.6× less memory. Plugin creation is ~3× faster with ~10× less memory. Normalization throughput went from ~49k to ~77k req/s in their internal benchmarks. These are self-reported numbers — treat them as directional, not absolute.

Two 1.3 changes to know before upgrading:

The error() function is deprecated in favor of status(). The old name works for now but will be removed around v1.4–1.5. Update your error handlers.

Eden Treaty’s .index suffix is gone. If your client code calls app.users.index.get(), it’s now app.users.get(). This is a breaking change for existing Eden clients.

What to watch: Cloudflare Workers support is still marked experimental as of v1.4.7. It requires CloudflareAdapter, a mandatory .compile() call before export, and compatibility_date: "2025-06-01" or later in your wrangler.toml. Static file serving doesn’t work (no fs module). If CF Workers is a real deployment target — not a contingency — don’t depend on this path yet.

import { Elysia, t } from 'elysia'

const app = new Elysia()
  .get('/health', () => ({ ok: true }))
  .post('/users', ({ body }) => ({ id: 1, ...body }), {
    body: t.Object({
      name: t.String(),
      email: t.String({ format: 'email' }),
    }),
  })
  .listen(3000)

export type App = typeof app

// Client — same monorepo, no codegen
import { treaty } from '@elysiajs/eden'
import type { App } from '../server'

const client = treaty<App>('http://localhost:3000')
const { data } = await client.users.post({ name: 'Alice', email: '[email protected]' })

Hono

Hono’s value proposition is runtime portability. One app definition runs on Cloudflare Workers, Node.js, Bun, Deno, Vercel Edge, Netlify Edge, and AWS Lambda — without adapter flags or compile calls. Cloudflare’s official framework guides list Hono as a supported choice. If your deployment target is Cloudflare Workers, Hono is the obvious pick.

The API is deliberately minimal. Route definitions look like Express, middleware follows the (c, next) pattern, and you bring your own validation library. This is a feature, not a gap — Zod, Valibot, and ArkType all integrate cleanly, and you’re not locked into TypeBox.

Hono’s RPC client (hc<AppType>(url)) does roughly what Eden Treaty does: infer the client type from the server definition. It requires app.route() composition to expose types correctly, which adds a small structural tax the Eden Treaty path doesn’t have. Post v4.10.0, middleware types propagate correctly through the chain — this was a long-standing rough edge.

The ecosystem advantage is real. Hono has more community middleware, more integrations (Sentry, Stripe webhooks, JWT, rate-limiting), and more Stack Overflow answers. For a small team shipping quickly without deep framework knowledge, that breadth matters.

What to watch: Hono doesn’t include built-in validation. Calling c.req.json() returns any. You need to wire up a validator middleware (the Zod validator package is first-party, maintained by the Hono team) to get typed, validated bodies. It’s a two-step setup that Elysia handles in one.

import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

app.get('/health', (c) => c.json({ ok: true }))

app.post(
  '/users',
  zValidator('json', z.object({ name: z.string(), email: z.string().email() })),
  (c) => {
    const body = c.req.valid('json') // typed
    return c.json({ id: 1, ...body })
  }
)

export default app
export type AppType = typeof app

// Client
import { hc } from 'hono/client'
import type { AppType } from '../server'

const client = hc<AppType>('http://localhost:3000')
const res = await client.users.$post({ json: { name: 'Alice', email: '[email protected]' } })
const data = await res.json()

Head-to-head

Type-safe clients

Both clients are usable. Elysia’s Eden Treaty has a flatter call shape — client.users.post(body) — and no need to separately import a validator package. Hono’s hc client mirrors the HTTP method naming convention more explicitly (.$post(), .$get()), which some teams prefer for clarity.

Eden Treaty’s inference is faster (up to 13× per Elysia 1.0 self-reported IDE benchmarks) — meaningful if your IDE is sluggish on large type graphs. Hono’s inference is correct post v4.10.0 but doesn’t advertise speed numbers.

One practical difference: Elysia’s client is Bun-first. If your frontend runs on the browser or another runtime, you need @elysiajs/eden on the client side and it needs to be able to import the server type. In a monorepo this is standard. In a polyglot setup it requires coordination. Hono’s hc targets cross-runtime use from day one.

Validation DX

Elysia’s built-in t.* schema is lower friction for greenfield projects. One package, one import, one call. The TypeBox integration means the same schema object drives both runtime validation and TypeScript inference.

Hono’s approach is more flexible. You can swap Zod for Valibot, use different validators on different routes, or skip validation entirely on internal routes where performance matters. That flexibility has a setup cost — you’re stitching together two packages instead of one.

Cloudflare Workers

This is the clearest differentiator. Hono: no caveats, production-ready, Cloudflare-endorsed. Elysia: experimental, with documented feature gaps (no static file serving, no pre-start Response construction). If CF Workers is in scope, this is the deciding factor.

Community and ecosystem

Hono has 30,678 GitHub stars vs. Elysia’s 18,418 (May 2026). More stars don’t guarantee a better framework, but they correlate with more answered Stack Overflow questions, more maintained third-party plugins, and a lower probability that the project stalls. Elysia is growing too — the framework is active and SaltyAom ships frequently — but the gap is real.

When to pick which

Pick Elysia if:

You’re on Bun exclusively, with no plans to run on Node.js or CF Workers.
You’re building a monorepo where a frontend and backend share types, and you want Eden Treaty’s zero-codegen RPC client.
Built-in validation with one package is worth more to you than ecosystem breadth.
You’re comfortable pulling updates promptly — Elysia ships breaking changes, and 1.3 has already deprecated error().

Pick Hono if:

Cloudflare Workers is a deployment target, even a future one.
You need your server to run on Node.js, Deno, or other runtimes in addition to Bun.
You want a larger ecosystem, more middleware options, or more community resources.
You prefer separating validation library choice from framework choice.

Verdict

For most teams starting a new Bun project in 2026, Hono is the safer default. The CF Workers story is solid, the multi-runtime support means you’re not locked in, and 30k stars means you’ll find answers when you get stuck. The extra validator setup is a one-time cost.

Elysia is the right pick when you know you’re staying on Bun and you want Eden Treaty’s type-safe client without any ceremony. If you’ve tried Hono’s hc client and found the .$post() / .$get() naming awkward, Elysia’s call shape is genuinely nicer. Keep the 1.3 breaking changes and the experimental CF Workers adapter in mind before committing.

Caveats

We did not benchmark either framework ourselves. Performance numbers in the Elysia section are self-reported by the Elysia team. For independent throughput comparisons, check bun-http-framework-benchmark and run the suite on your own hardware. This article contains affiliate links.