Redwood JS is a full-stack React + Node framework that ships GraphQL by default, a Cell pattern for declarative data fetching, Prisma for the database, and a deploy story aimed at serverless and traditional infrastructure. The right answer is yes for teams that want GraphQL without the wiring (cells, services, GraphQL resolvers are scaffolded for you), and no for teams that want a pure SPA with no server. The framework is opinionated, the conventions save weeks of setup, and the deploy story is mature on the major platforms.
Table of contents
- The structure — three trees, one project
- The Cell pattern — declarative data fetching
- The GraphQL story — schema-first, generated, typed
- The deploy story — serverless and traditional, with the same commands
- When to pick Redwood (and when not to)
- How this fits the rest of the stack
- FAQ
The structure — three trees, one project
A Redwood project has three top-level trees: web/ (the React frontend), api/ (the Node + GraphQL backend), and db/ (the Prisma schema). The two runtimes are separate processes that share a generated GraphQL schema. The frontend imports from the backend through a single import path (import { posts } from 'src/graphql'), and the build system handles the cross-tree types.
The right answer for a team that has been writing React on the frontend and Express on the backend and stitching the two together with a REST client is to look at Redwood. The conventions eliminate a category of integration bugs, and the project structure is consistent across the team.
The Cell pattern — declarative data fetching
The Cell is the right answer for ‘I need to load this data, show a loading state, show an error state, show the empty state, and render the data.’ A Cell is a single file with named exports for QUERY, Loading, Error, Empty, Success, and the React component just renders <MyCell />. The Cell handles the lifecycle, the GraphQL query is the data, the named exports are the states.
The convention replaces the same 30 lines of useState + useEffect + try/catch that every team writes in every SPA. The right answer for a team that has more than 20 components fetching data is Redwood. The wrong answer is the Cell for the team’s single-page demo — the cell’s boilerplate is overkill for a 50-line app.
The GraphQL story — schema-first, generated, typed
Redwood ships GraphQL by default. The team’s SDL file defines the schema, the resolvers live in api/src/graphql/, the services live in api/src/services/, and the build generates the typed client for the frontend. The type flows from the database (Prisma schema) to the service to the GraphQL schema to the generated frontend client, end to end, with no manual type definitions.
The gotcha: GraphQL is opinionated. The team that wants REST, or wants RPC, or wants no schema at all, is fighting Redwood’s defaults. The right answer is to adopt Redwood when the team agrees on GraphQL as the API shape. The wrong answer is to use Redwood and then disable GraphQL — the framework’s main benefit is the generated types, and disabling the schema removes the benefit.
The deploy story — serverless and traditional, with the same commands
Redwood has a first-class deploy command (yarn rw deploy). The supported targets are serverless (Netlify, Vercel, AWS Amplify) and traditional (Render, Fly, Railway, custom Node host). The command handles the build, the function packaging, the env var injection, and the migration step. The team’s first deploy takes 10 minutes; subsequent deploys take 60 seconds.
The gotcha: the serverless target requires the team to use the serverless Postgres options (Neon, Supabase) — the traditional db push does not work on serverless. The right answer is to pick a database provider that works with the deploy target.
When to pick Redwood (and when not to)
Pick Redwood when the team wants GraphQL, wants Prisma, wants a Cell pattern for data fetching, wants first-class auth scaffolding, and is willing to live with the framework’s opinions. The right answer is yes for a startup shipping the first version, a small team that wants to ship in weeks, a team that has been struggling with the integration layer between React and Node.
Don’t pick Redwood when the team wants a pure SPA with no server, wants REST or RPC instead of GraphQL, wants a non-Postgres database, or wants maximum flexibility over the build pipeline. The right answer for those cases is a different framework (Next.js for the SPA story, Express + tRPC for the typed RPC story, NestJS for the REST story).
The framework is a tool, not a religion. The right answer is to pick the framework that gets the team from zero to production fastest, then graduate when the project’s needs outgrow the framework’s defaults.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is Redwood JS?
A full-stack React + Node framework that ships GraphQL by default, a Cell pattern for declarative data fetching, Prisma for the database, and a deploy story aimed at serverless and traditional infrastructure.
Is Redwood JS still maintained?
Yes. The active branch is the v6 line as of 2025, with regular releases. The right answer is to check the GitHub release frequency before committing.
What is a Cell in Redwood?
A Cell is a single file with named exports for QUERY (the GraphQL query), Loading, Error, Empty, and Success. The Cell handles the data-fetching lifecycle.
What is the difference between Redwood and Next.js?
Redwood is full-stack (React + Node + GraphQL + Prisma). Next.js is React-first with optional SSR, server actions, and route handlers.
Can I use Redwood with a non-Postgres database?
Prisma’s Postgres/MySQL/SQLite support is the strongest, and Redwood assumes Prisma. The right answer for a team that needs MongoDB or DynamoDB is a different framework.
Where do I deploy Redwood?
Netlify, Vercel, AWS Amplify, Render, Fly.io, any custom Node host. The yarn rw deploy command handles the build, env vars, and migration.
Does Redwood work with TypeScript?
Yes. TypeScript is the default in v6+, and the generated GraphQL client is typed end to end.
Is Redwood production-ready?
Yes. Several SaaS companies run Redwood in production. The right answer is yes for a team that agrees on GraphQL + Prisma, has 2-5 engineers, and wants to ship in 4-8 weeks.