Compare RedwoodJS
Stacks vs RedwoodJS

Same ambition, different bets.

Redwood set out to be the full-stack framework JavaScript never had, and much of it landed: generators, cells, Prisma-backed services, auth providers, and background jobs. Stacks wants the same thing and made different choices about the runtime, the transport, and how much of the infrastructure belongs in the repository.

See what ships All comparisons

What RedwoodJS is.

In its own terms, not ours.

RedwoodJS pairs a React front end with a services layer, originally over GraphQL and more recently over an RSC-first architecture in Redwood SDK. It leans on Prisma for data, supports several auth providers, and ships generators that scaffold both halves of a feature. Its opinionated, batteries-included stance is the closest philosophical neighbour Stacks has in JavaScript.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick RedwoodJS for

  • React and GraphQL maturity

    If you want React on the front and a schema-first API in the middle, Redwood has years of that path worn in.

  • Prisma

    Prisma is a superb, widely known ORM with excellent tooling, and Redwood is built around it.

  • Established community

    Redwood has been shipping since 2020, with a larger user base and more third-party writing than Stacks has.

  • Cells

    The cell pattern for loading, empty, failure, and success states is a genuinely good idea for data-driven interfaces.

Pick Stacks for

  • One runtime

    Bun for the server, the tests, the CLI, and the build, with no separate bundler configuration to reconcile.

  • More in the box

    Mail, notifications, SMS, push, search indexing, storage, realtime, commerce, CMS, and an admin dashboard are first-party rather than integrations.

  • Infrastructure included

    DNS, TLS, CDN, and mail records are declared in config and applied by buddy deploy, without a separate infrastructure tool.

  • Model-driven migrations

    Schema comes from the model definitions and is diffed into SQL, rather than being maintained in a separate schema file.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks RedwoodJS
Front end STX components React, with RSC in Redwood SDK
API transport REST with generated OpenAPI GraphQL historically, RSC and server functions now
Data layer First-party ORM, models drive migrations Prisma schema drives migrations
Auth First-party sessions, tokens, passkeys, RBAC dbAuth or a third-party provider
Background jobs Queues, batches, schedules, workers Background jobs with a database queue
Runtime Bun Node.js
Admin surface Dashboard generated from models Scaffold generators produce CRUD pages
Infrastructure Declared in config/cloud.ts Deploy targets and your own IaC

If you did move.

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

Services become actions

A Redwood service function is close to a Stacks action: one job, typed input, typed result.

Prisma schema becomes models

Each Prisma model maps to a defineModel() with attributes and relationships, after which migrations are generated for you.

GraphQL consumers need a plan

Stacks is REST-first. A client depending on GraphQL needs either a gateway or a client rewrite.

The verdict.

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

Choose RedwoodJS when

You want React and GraphQL with an opinionated full-stack structure, and Prisma is a dependency you are happy to build on.

Choose Stacks when

You want the same completeness but on Bun, over REST, with mail, search, storage, realtime, and the deploy included.

The frameworks that usually come up in the same conversation.

Stacks vs Next.js

The React meta-framework. Stacks answers the backend questions Next.js deliberately leaves open.

Stacks vs The T3 Stack

Best-in-class parts, assembled by you. Stacks is the same territory, maintained as one thing.

Stacks vs AdonisJS

The other Laravel-inspired TypeScript framework. The closest comparison on this page.