open-saas is a Wasp template you copy, and each Wasp version gets its own release

Releases are named for Wasp versions, so the template moves on the framework's clock

The three most recent releases are not numbered on their own. They are `wasp-v0.26-template` on 2026-10-15, `wasp-v0.25-template` on 2026-07-27 and `wasp-v0.24-template` on 2026-06-11, each one labelled as OpenSaaS for that Wasp version.

That naming is the whole upgrade story. The template is not versioned independently of the framework underneath it; it is versioned by it. A template release exists because a Wasp release exists, which means the cadence of your SaaS codebase is set by Wasp's release cadence rather than by anything you need from the template itself.

The cost shows up the first time Wasp moves ahead. If a new framework version ships before a matching template release exists, you have a choice with no good branch: stay on the old template and forgo the framework upgrade, or upgrade Wasp and carry the template diff yourself. Neither option is documented as a procedure in the README, so both amount to reading the diff. Plan for that review rather than treating the template as something you pull forward on demand.

The last push to the repository was on 2026-10-28, so the template itself is not the stale part here. The dependency on Wasp's release rhythm is.

Two commands produce a directory that is yours to maintain

The setup is two commands. First the Wasp CLI, on macOS, Linux, or Windows with WSL:

npm i -g @wasp.sh/wasp-cli

Then the template itself:

wasp new -t saas

What that second command does is create a clean copy of the Open SaaS template into a new directory. Clean copy is the phrase that matters, and it is the difference between a starter and a dependency. You are not adding open-saas to a manifest. You are materialising a snapshot of its source into your own repository, and from that point every line in it is yours.

The documentation site reflects that arrangement. Alongside installation instructions it carries a guide to pulling updates to the template, alongside guides for integrating services, SEO and deployment. A page about pulling updates is only necessary in a copy-and-merge world, which confirms the shape: template improvements arrive as commits you merge by hand, and every merge is a conflict surface against the code you have since changed.

So the honest way to evaluate this is not as free features but as a code donation. The question is how much of `template/` you intend to keep untouched.

Windows is covered through WSL, and the Node version is pinned per repository

Platform support is stated in one line: the CLI installs on macOS, Linux, or Windows with WSL. Windows with WSL is the whole of the Windows story, so a team on native Windows needs a Linux environment before the first command runs. There is no PowerShell path and no native binary mentioned anywhere.

The repository root carries a `.nvmrc` next to a `.npmrc`, which fixes the Node version the project is developed against and pins npm behaviour for it. That detail sits oddly against the version story in the previous section. The template's own tooling is pinned to a known Node version, while the framework it generates code for moves on its own release schedule. Two independent clocks, and only one of them is under the template's control.

For a reader sizing the environment, the practical list is short: Node matching `.nvmrc`, the Wasp CLI installed globally through npm, and a deployment target. What is not on the list is a container definition. The repository does not ship a Dockerfile at the top level, so the repeatable environment a team needs for CI has to be built by whoever adopts the template, not inherited from it.

The root package.json is called wasp-repo and defines no test script

The repository root is a tooling harness rather than the application. Its manifest is named `wasp-repo`, declares `"type": "module"`, and defines four scripts:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "prettier:check": "prettier --ignore-unknown --check --config prettier.config.ts .",
    "prettier:format": "prettier --ignore-unknown --write --config prettier.config.ts ."
  }
}

Both formatter scripts pass `--ignore-unknown`, so binary and unrecognised files are skipped instead of failing, and both name `prettier.config.ts` explicitly rather than relying on discovery. The configuration is a TypeScript file.

What the manifest does not define is a test script. The feature list names Playwright for end-to-end tests, but nothing at the root launches it. So the suite the template advertises is not reachable from the repository root, and anyone who clones this expecting `npm test` to run end-to-end checks will find no such command. The top-level layout explains why: the application lives under `template/`, the marketing site under `opensaas-sh/`, and another derived project under `template-test/`, with the shared developer tooling in `tools/` and its own README.

Prettier and its plugins are pinned exactly, while ESLint floats within its major

The dependency ranges in that manifest are not uniform, and the split is deliberate enough to be worth reading. Prettier is fixed at `3.8.1` with no range operator, and three of its plugins are fixed the same way: `prettier-plugin-organize-imports` at 4.3.0, `prettier-plugin-pkg` at 0.22.1 and `prettier-plugin-sh` at 0.18.1. A fourth, `prettier-plugin-tailwindcss`, uses a caret instead.

The linting side floats. `eslint` is at `^9.39.4`, `@eslint/js` at `^9.39.4`, `eslint-plugin-react` at `^7.37.5`, `eslint-plugin-react-hooks` at `^7.0.1`, and both `@typescript-eslint` packages sit at `^8.58.1`. TypeScript itself is exact at 5.9.3.

The consequence shows up in CI, where both checks run automatically on every pipeline. Formatting is deterministic: an exact pin means the formatting output cannot change under you, so `npm run prettier:check` fails only when a human changed a file. Lint results can move without any commit at all, because a fresh install inside the caret range can pick up a new minor or patch release. If you adopt the template, that means a formatting failure is your change while a lint failure might be the toolchain's, and knowing which one you are looking at saves a wasted afternoon.

Provider choices run three deep, and the README hands them to the docs site

The feature list is generous and deliberately unopinionated about vendors. Payments can go through Stripe, Polar.sh or Lemon Squeezy. Email through SendGrid, MailGun or SMTP. Analytics through Plausible or Google Analytics. Files through AWS S3. There is an OpenAI API example built on function calling, Shadcn UI for components and styling with an admin dashboard, Astro's Starlight template for the documentation and blog, and Playwright for end-to-end tests.

None of that comes with the specific integration steps. The README states that everything needed for getting started and using the template is in the Open SaaS Docs, which covers installation, pulling template updates, guides for integrating services, SEO and deployment. For a reader evaluating the template, that sentence is the most important one in the file. The repository shows you the shape of a finished SaaS and the catalogue of choices; the paid part of the work, knowing how to swap Plausible for a different analytics provider inside generated Wasp code, is in documentation you have to go and read.

So treat the feature list as a table of contents for the app you would get, not as a list of things that work the moment the directory exists. Which is also why the copy semantics from the second section matter: every provider you keep is a file you now own.

The template ships agent instructions and admits its own feature set is incomplete

Point four of the template's own list is that it is ready to work with your favourite AI coding tool or agent, naming Claude Code, Cursor, Codex and OpenCode. The supporting description is a tailored AGENTS.md, skills and a Claude Code plugin, and the feature list calls out custom plugins, skills and rules for AI-assisted coding.

That is a real differentiator for teams working this way, and it is also the part most exposed to churn. Agent instruction files, skill formats and plugin manifests are tied to specific tools, and the template can only carry versions of them that worked when it was cut. Nothing in the repository pins which tool versions the instructions were written against, so after a few months the honest test is whether your agent still follows them, and the template cannot answer that for you.

The contributing note is worth reading with the same attention. It says the maintainers have tried to get as many core SaaS features into the template as possible, but that there still might be some missing features or functionality. A template that documents its own gaps is more trustworthy than one that claims completeness, and it also means the missing pieces are yours. Between the unstated agent-file compatibility and the admitted feature gaps, the fairest summary is that this is a fast start you finish yourself.

Two support routes are named: opening an issue on the repository, or the Wasp Discord server, with questions directed to a forum channel.

Editorial conclusion

Reach for open-saas when you want a Wasp app with auth, payments and background jobs already built and you are willing to own the generated code, because that copy is exactly what the template produces. Skip it if you need to move framework versions on your own schedule, or if you want template fixes to arrive as an upgrade rather than as a merge. Before you start, check which Wasp release the template you are cloning targets, and read the guide to pulling template updates, because that merge is the ongoing cost.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wasp-lang/open-saas on GitHub