RedwoodSDK: server-first React for Cloudflare Workers

RedwoodSDK's Cloudflare-specific server-first React model

RedwoodSDK addresses a specific gap between ordinary client-side React applications and full-stack React architectures built around server rendering. It is for developers who want React components and Server Functions to participate in server-side data access while the final application runs on Cloudflare's workerd runtime. The project is not described as a general-purpose Node.js framework. The README explicitly limits it to Cloudflare, so a deployment target outside workerd is a reason to stop evaluating it as-is.

The framework starts with Vite and adds React Server Components, Server Functions, routing, middleware, and primitives intended for realtime applications. Its center of gravity is server-first rendering, which means application code can fetch data through server functions before a React Server Component renders the result. This is a concrete fit for Cloudflare applications that combine page rendering with API-like routes, redirects, generated XML, text files, or other Web `Response` output.

The intended audience is therefore narrower than the phrase "React framework" may suggest. RedwoodSDK fits developers who accept Cloudflare's runtime model, want TypeScript-first code, and prefer routing based on standards-oriented request handling. It may be a poor choice for an application whose hosting platform cannot execute workerd, even if the React portion of that application would otherwise be compatible.

How RedwoodSDK routes requests and renders React

The routing model follows a simple rule: a route returns a valid `Response`, or it can return a React element that the framework renders into that response. `defineApp` receives an application definition, while `render` supplies the document renderer. Individual handlers are registered with `route`, which associates a path with a function. The resulting router is described as type-safe and based on Web standards rather than framework-specific magic.

This design keeps several response types in one route tree. A handler can return plain text, redirect with status `301`, emit XML for a sitemap, or render a React page. That is useful when a project needs a conventional application surface without introducing a separate HTTP framework for every resource. Middleware can operate at the application level or on individual routers, giving handlers shared control over requests and responses.

Realtime support is described through "realtime-ready primitives," but the README does not explain their implementation, connection model, persistence requirements, or deployment configuration. That wording should be treated as a capability claim rather than a complete specification. A team considering subscriptions, broadcasts, or presence should inspect the linked documentation for the relevant API and Cloudflare binding before assuming those cases are covered.

Creating a RedwoodSDK project and starting Vite

The documented quickstart creates the project first, changes into its directory, installs dependencies with pnpm, and starts the Vite development server. The generated directory name in the example is `my-project-name`.

npx create-rwsdk my-project-name

After the generator finishes, install the generated project's dependencies:

cd my-project-name
pnpm install

Start the development server:

pnpm dev

The README shows Vite at `http://localhost:5173/` and states that Vite 6.2.0 is ready. The exact timing printed by the development server is environment dependent and should not be treated as a performance guarantee.

For contributors working with the repository rather than a generated app, the monorepo requires Node.js `>=24.14.0` and pnpm `>=11.0.0`. It also declares `[email protected]` as its package manager. These requirements apply to repository development and should not be confused with the separate `create-rwsdk` application workflow shown in the quickstart.

Defining the first RedwoodSDK route tree

The first useful application change can be made in `worker.tsx`. The following abbreviated example preserves the README's imports, route paths, and response semantics while omitting its app-page import.

import { defineApp } from "rwsdk/worker";
import { route, render } from "rwsdk/router";

export default defineApp([
  render(Document, [
    route("/", () => new Response("Hello, World!")),
    route("/ping", function () {
      return <h1>Pong!</h1>;
    }),
  ]),
]);

The root route returns a text `Response`, while `/ping` returns JSX for the renderer. In a complete project, `Document` must be defined in the application. The README does not provide its implementation, so copying only this abbreviated route tree is not enough to reconstruct the whole file.

The same router can also handle redirects and non-HTML content:

route("/docs", async () => {
  return new Response(null, {
    status: 301,
    headers: {
      "Location": "https://docs.rwsdk.com",
    },
  });
});

This illustrates the framework's central routing constraint. A handler is responsible for producing a valid result, including status and headers when needed. RedwoodSDK does not require every endpoint to be a React page.

Calling server data from a React Server Component

Server Functions connect data access to React Server Components. The README marks `users.ts` with `"use server"` and exports `getUsers`, which reads from an application database through the `@/db` alias. A component then awaits that function and maps the returned records into list items.

"use server";
import { db } from "@/db";

export async function getUsers() {
  const users = await db.users.findAll();
  return users;
}

The component consumes the same exported function:

import { getUsers } from "./users";

export default async function UsersPage() {
  const users = await getUsers();
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

The `db` implementation is application-specific and is not included in the README, so the example does not tell a reader which Cloudflare database service or binding to configure. It also does not document authentication, authorization, serialization boundaries, validation, or transaction handling for Server Functions. Those are material concerns for any route that accesses user data, and they must be verified in the project documentation and generated application before adoption.

Cloudflare workerd constraints and wrong-tool cases

The clearest limitation is also the easiest to overlook: the README states "For Cloudflare (workerd) only." RedwoodSDK should not be selected merely because a team likes server-first React. If the application must run on a conventional Node.js server, another edge platform, or a static hosting target without workerd compatibility, this framework's stated target does not match the deployment requirement.

The project also offers less abstraction than frameworks with integrated ORM layers, authentication systems, or deployment presets. The README leaves the database implementation open through `@/db`. It documents a router, render integration, middleware, and server functions, but it does not claim that RedwoodSDK supplies a complete data layer or authentication model. Developers expecting those capabilities as part of the framework should not infer them from the broad "full-stack React" description.

There is a second practical limit in the README. It provides no rollback procedure for Cloudflare deployments, no database migration guide, and no explanation of how realtime primitives connect to a particular transport. Those omissions do not prove the features are absent, but they mean the README alone is insufficient for production planning. Each must be checked against `docs.rwsdk.com`, the generated project, and Cloudflare-specific configuration.

Alternatives, maintenance signals, and upgrade work

A real alternative is to use a general Cloudflare web framework or write request handlers directly against workerd, adding React rendering only where server-rendered pages are required. That approach does less framework-level setup, but it also requires the application team to define component rendering, function boundaries, routing composition, and middleware integration itself. RedwoodSDK's distinction is that these pieces are assembled around Vite and React Server Components from the start.

Another option is a React framework centered on a different deployment runtime. Such a project may fit an existing Node.js architecture better, but it does not provide the Cloudflare-specific fit stated by RedwoodSDK. The choice should therefore follow runtime and application requirements, not the amount of React syntax in the interface.

The repository is not archived, and its last push was on 2026-10-12. Recent releases include v1.7.4 on 2026-09-23, v1.7.3 on 2026-09-03, and v1.7.2 on 2026-08-13. These are concrete signs of recent repository and release activity, but the README does not document a long-term support window or an application upgrade path. The repository contains `SUPPORT.md`, which is the first named place to check before relying on a particular release line.

The project is licensed under the MIT License. Its `LICENSE.md` file is the applicable source for redistribution and notice obligations. Maintainers should also inspect `pnpm-lock.yaml`, package-level release notes, and migration notes before changing SDK versions in an existing application.

Editorial conclusion

Developers should consider RedwoodSDK when their application runs on Cloudflare workerd and its server-first React model fits the project. Developers needing another runtime, a conventional Node server, or established non-React behavior should look elsewhere. Before adoption, verify the generated project's Cloudflare configuration, route behavior, Server Function boundaries, and deployment workflow against application requirements.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. redwoodjs/sdk on GitHub
5. Releases