Stacks vs Elysia

Both are Bun-first. One is a router, one is an application framework.

Elysia is the strongest argument for Bun on the server: schema-validated routes, inferred types, an Eden client with no code generation, and throughput near the top of public benchmarks. Stacks shares the runtime bet and answers a different question, which is everything you need once the router is chosen.

What Elysia is.

In its own terms, not ours.

Elysia is built for Bun first, with adapters for Node, Deno, and Workers, and uses Bun to do things portable frameworks cannot, including a JIT compiler that builds optimised handlers per route. TypeBox or any Standard Schema library such as Zod validates requests and produces types, plugins compose cleanly, and Eden gives a fully typed client. For a high-performance Bun API it is an excellent choice.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Elysia for

  • Raw performance

    Elysia is faster at the routing layer than a full framework will be, and if requests per second per core is your metric, it wins.

  • Eden

    Eden infers types from every route with no opt-in. Stacks has a typed client with no generation step too, but only for routes registered through its typed router.

  • Small surface

    Fewer concepts to learn, and nothing you do not use.

  • Plugin composition

    The plugin model is clean and makes sharing behaviour between services straightforward.

Pick Stacks for

  • Batteries, not building blocks

    ORM, migrations, auth, RBAC, queues, mail, storage, search, realtime, CMS, commerce, and an admin dashboard.

  • Views and assets

    A front end in the same project: SSR, static generation, islands, and SPA navigation, with a component model and Crosswind styling.

  • Structure that survives growth

    Conventions for where things live, so the tenth feature looks like the first.

  • Deploy and operations

    Infrastructure from config, a dashboard for jobs and mail, and CI that ships on push.

  • Your own mail server

    Stacks ships an SMTP and IMAP server, so hello@ and support@ on your domain are real mailboxes on your own box, readable in Mail.app or any client. buddy mail:provision creates them and their MX, SPF, DKIM, and DMARC records. None of the frameworks compared here ships one.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Elysia
Scope Full application framework HTTP framework
Runtime Bun today, more runtimes planned Bun first; Node, Deno, Workers adapters
Validation On model attributes TypeBox or Standard Schema per route
Client types Typed client, no generation step; OpenAPI too Eden, inferred
Data layer Included Choose your own
Background work Included Choose your own
Views STX: SSR, static, islands HTML/JSX plugin or a template engine
Raw throughput Good, with a framework in the path Best in class
Mail server Built in: SMTP, IMAP, real mailboxes None; inboxes come from a hosted provider

If you did move.

What ports cleanly, what does not, and where to start.

Same runtime, so no rewrite of the primitives

Bun APIs, native SQLite, and package resolution behave the same on both sides.

Schemas become model validation

Route schemas, TypeBox or Standard Schema, move onto attributes, where the factory and the generated API also use them.

Eden consumers switch clients

Clients move from Eden to the Stacks typed client, which keeps inferred types but changes the call shape, and is the main piece of work.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Elysia when

The service is an API, throughput is the requirement, and you want the thinnest possible layer over Bun.

Choose Stacks when

You want the same runtime with the rest of the application already written and typed together.

The frameworks that usually come up in the same conversation.