# Wasp: a declarative full-stack framework for React, Node.js and Prisma

> Wasp compiles a single .wasp.ts specification plus your own React and Node.js files into a complete web app. It suits small teams that want auth, RPC and jobs without wiring them by hand, and it is still beta software at v0.25.0.

**wasp-lang/wasp** — The batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.

- Repository: https://github.com/wasp-lang/wasp
- Website: https://wasp.sh
- Stars: 18,736 · Forks: 1,472
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wasp-lang-wasp

## The boilerplate problem Wasp is aimed at

A typical React plus Node.js app repeats the same wiring on every project: a session or token layer, a router, a data-fetching client, a server that exposes endpoints, an ORM, and the glue that keeps the client and server types in agreement. None of that is product logic, and all of it has to be maintained and upgraded.

Wasp's answer is to move the high-level description of the app into a specification file. The README calls Wasp a Rails-like framework for React, Node.js and Prisma, and the stated goal is that you can create and deploy a production-ready web app from scratch with very few lines of concise, declarative code. The audience is a developer or small team that already knows React and Node.js and does not want to hand-assemble auth, RPC, background jobs and email sending for the fourth time.

The README also positions Wasp for AI-assisted work, arguing that a high-level spec of the whole app gives agents clearer guardrails and less boilerplate to manage. That is a claim about how models behave rather than a technical property, but it follows from the design: the spec is a compact description of the whole system, and the repository ships official agent plugins for tools such as Cursor and Claude Code.

## How the Wasp compiler turns a spec into a running app

The mechanism is a compiler, not a runtime library. You write main.wasp.ts, which imports app, page, query and route from @wasp.sh/spec, and you reference your own React components and Node.js functions with { type: "ref" } imports. The README states that from that specification plus your .ts(x) and .css source files, Wasp generates the whole source of your web app in the target stack: front-end, back-end and deployment.

That generated code lands in the .wasp/ directory, and the README points to it explicitly as evidence that there is no lock-in, since you can read what was produced. This is the design decision worth understanding before you adopt anything: you debug against generated Express routes and generated client code as well as your own files, and an upgrade of Wasp can change what is generated underneath you.

The spec carries information that would otherwise be scattered. A route declares its path and page, and an authRequired flag on that page limits access to logged-in users. A query declares the entities it touches, which the README says drives automatic cache invalidation. Auth is declared as a userEntity plus methods such as email and google, with onAuthFailedRedirectTo pointing at a login route. The database side is a normal Prisma schema file, so the model Task in schema.prisma is plain Prisma.

One constraint is stated plainly in the README: while the idea is to support multiple web tech stacks in the future, Wasp currently focuses on React with TanStack Query, Node.js with Express.js, and Prisma. Choosing Wasp means choosing that stack.

## Installing the Wasp CLI and running a first app

The README gives one install command for OSX, Linux and WSL on Windows. It installs the CLI globally from npm:

```bash
npm i -g @wasp.sh/wasp-cli@latest
```

After that, the README says to follow the instructions to run your first app in less than a minute, and points to the quick-start page at wasp.sh/docs/quick-start for a fuller walkthrough. The repository also carries a TodoApp tutorial under examples/tutorials, which the README calls a complete code example.

The shape of a first app is a spec file. This is the example the README gives, trimmed to its structure: an app declaration with a name, a wasp version range, a title, and a spec array of routes and queries.

```ts
// file: main.wasp.ts
import { app, page, query, route } from "@wasp.sh/spec";
import { MainPage } from "./src/MainPage" with { type: "ref" };
import { getTasks } from "./src/queries" with { type: "ref" };

export default app({
  name: "todoApp",
  wasp: { version: "^0.24.0" },
  title: "ToDo App",
  spec: [
    route("RootRoute", "/", page(MainPage)),
    query(getTasks, { entities: ["Task"] }),
  ],
});
```

The data model lives in Prisma, not in the spec. The README's example declares a Task model with an autoincrementing integer id, a description string and an isDone boolean defaulting to false.

```prisma
// file: schema.prisma
model Task {
  id          Int     @id @default(autoincrement())
  description String
  isDone      Boolean @default(false)
}
```

Everything else is ordinary React and Node.js code that the spec references. When you run the app, the generated project appears under .wasp/, and that directory is where you look when a request behaves differently from what the spec suggests it should.

## Beta status and the upgrade surface it creates

The README's project status section is direct: Wasp is in beta, with most features fully developed and functioning well, but with many improvements and additions planned, and you can expect numerous changes and improvements in the future. That is not a formality. A framework that generates your front-end, back-end and deployment code concentrates upgrade risk in one place, and a change in generated output can affect code you never wrote.

The versioning reflects this. The most recent release listed is v0.25.0 from 2026-07-27, preceded by a release candidate, v0.25.0-rc.1, on the same day, and v0.24.0 on 2026-06-11. Zero-major version numbers with release candidates in front of them are a reasonable signal that the maintainers treat compatibility as unsettled. The last push to the repository was on 2026-09-18, so the project is being worked on, but that says nothing about whether your spec will still compile after the next release.

The practical consequence is that the wasp.version field in your spec is not decoration. The README example pins it to ^0.24.0, and that range is the contract between your code and the compiler that generates it. Treat a Wasp upgrade the way you would treat a major framework migration: read the release notes, run it on a branch, and inspect the diff in .wasp/ before it reaches anything that matters.

Wasp is also the wrong tool when your stack is already settled elsewhere. If you are on a different ORM, a different server framework, or a front-end other than React with TanStack Query, the abstraction has nothing to abstract. The same applies if you need fine control over the HTTP layer: the generated Express server is a starting point, not a configuration surface the README documents.

## Wasp against hand-assembled stacks and meta-frameworks

The closest comparison is not a single named competitor but the thing Wasp replaces: a hand-assembled React and Node.js project where you pick a router, a session library, a data-fetching client and an ORM, then write the glue between them. That approach gives you complete freedom over each layer and no compiler between you and the output. Wasp trades that freedom for a spec file and generated code, and the README's argument for the trade is less boilerplate to maintain and easier upgrades.

A second comparison is to meta-frameworks that keep everything in one codebase and one language, typically JavaScript or TypeScript, with file-based routing and server functions. The difference in approach is where the app's structure lives. In those frameworks the structure is implied by the file tree and the exports inside your files. In Wasp it is declared explicitly in main.wasp.ts, which is what makes the spec a single readable description of routes, auth and queries, and also what makes the compiler a required step in your workflow.

The third comparison is to a full application platform that hosts what you build. Wasp takes the opposite position: the README states you can deploy the Wasp app anywhere you like, with no lock-in to specific providers, and that you have complete control over the code. The cost of that freedom is that deployment is your responsibility, and the CLI's single-command deployment is a convenience rather than a managed runtime.

## Licence, maintenance and what an upgrade actually costs

Wasp is MIT licensed, and the repository carries a LICENSE file at the root alongside SECURITY.md and CONTRIBUTING.md. MIT is permissive: you can use the framework in commercial and closed-source products, and the generated code in .wasp/ is yours to ship. This is a description of the licence text, not legal advice; if your organisation has rules about generated code or about the licences of transitive dependencies, check them against the actual dependency tree rather than against the framework's own licence.

Maintenance activity is visible in two places. The last push was on 2026-09-18, and the release history shows v0.25.0 on 2026-07-27 with a release candidate the same day. The repository is not archived. The README also states that the maintainers keep a development roadmap in a GitHub project, which is the place to look before you build a feature the framework does not yet cover.

The upgrade cost is the part teams underestimate. Because Wasp generates front-end, back-end and deployment code, an upgrade can change files you never edited, and the beta status section warns that numerous changes are coming. Budget for reading release notes and for a branch where you can diff .wasp/ output. The compensating factor is the same mechanism: because less of the app is handwritten glue, there is less of your own code to change when a dependency underneath moves.

## Conclusion

Adopt Wasp if you are building a React and Node.js product with a small team and you would rather describe auth, routes and queries in one spec file than assemble them yourself. Do not adopt it if you need a stack outside React, Express and Prisma, or if you cannot accept beta status and breaking changes between releases. Before committing, read the roadmap, pin wasp.version in your spec, and confirm that the generated .wasp/ output is something your team is willing to read and debug.

## FAQ

### How do I install the Wasp CLI?

The README gives a single npm command for OSX, Linux and WSL on Windows: npm i -g @wasp.sh/wasp-cli@latest. After installing, the README points to the quick-start page at wasp.sh/docs/quick-start for running your first app.

### Which tech stack does Wasp support?

The README states that Wasp currently focuses on one stack: React with TanStack Query on the front end, Node.js with Express.js on the back end, and Prisma for the database. It notes that supporting multiple web tech stacks is an idea for the future.

### Is Wasp production ready?

The README's project status section says Wasp is in beta, with most features fully developed and functioning well, but that numerous changes and improvements are expected in the future. The most recent release listed is v0.25.0.

### Does Wasp lock me into a hosting provider?

The README says you can deploy a Wasp app anywhere you like, with no lock-in to specific providers, and that you have complete control over the code. It points to the .wasp/ directory as the place to inspect the generated code.

## Sources

- [License: MIT](https://github.com/wasp-lang/wasp/blob/main/LICENSE)
- [Project website](https://wasp.sh)
- [README](https://github.com/wasp-lang/wasp/blob/main/README.md)
- [Releases](https://github.com/wasp-lang/wasp/releases)
- [wasp-lang/wasp on GitHub](https://github.com/wasp-lang/wasp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wasp-lang-wasp