# saas-boilerplate documents pnpm 9 and pins 10.26.2 > saas-boilerplate is a React, Django and AWS starter kit that gets six services running on a laptop with one command. The parts worth reading closely are the ones the page states plainly: an admin panel served from a subdomain of localhost, placeholder database and cloud credentials sitting in a committed compose file, a starter CLI that is compiled on every install, and a requirements list that disagrees with the package manager version the manifest enforces. **apptension/saas-boilerplate** — SaaS Boilerplate - Open Source and free SaaS stack that lets you build SaaS products faster in React, Django and AWS. Focus on essential business logic instead of coding repeatable features! - Repository: https://github.com/apptension/saas-boilerplate - Website: https://apptension.com/saas-boilerplate - Stars: 3,005 · Forks: 426 - Language: TypeScript - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/apptension-saas-boilerplate ## Six services, six ports, and one on a subdomain of localhost One command starts the stack, and the page then lists everything that is listening afterwards. The web app is on port 3000. The backend API is on 5001, described as Django with a GraphQL API. The admin panel is also on 5001 but on a subdomain of localhost rather than on the bare host. A mail catcher is on 1080 and catches all email locally. The documentation server is on 3006. And a workers trigger server is on 3005. The admin panel entry is the one that will cost somebody an afternoon. Serving it from a subdomain of localhost rather than from a different port means the local resolver has to answer for that name, which not every operating system does by default. Everything else in the table is a port, and ports always work. The three first steps are also specific. Open the web app and create an account. Then go to the mail catcher for the verification email. Then log into the admin panel using credentials from your env file. That ordering tells you the intended first run: signup is the only path that generates the credentials, and email verification is exercised for real rather than stubbed, which is why a mail catcher is in the stack at all. ## The compose file ships the database password and the cloud keys in plain text The development compose file is worth reading for its placeholders, because they are the values a new user starts from. The database service runs a pinned Postgres image and sets the user, the password and the database name to the same literal word, in four separate variables. The backend service sets an access key and a secret key to two literal placeholder strings, and a region. Both are obviously fake, and the file is obviously development only. That is normal. What makes it worth naming is the instruction that follows it in the documentation: if you do not have the env files, copy them from the shared templates, at the root and in the backend package. So the placeholders you can see in the compose file are the defaults you inherit, and the only step between them and a real database is a copy command. The rest of the file is careful in the ways that matter. The backend waits for the database and the cache to report healthy, and for the payment mock merely to have started. The cache health check increments a counter rather than pinging, so a check that passes means the server is answering writes. A mock of the payment provider's API runs alongside, which is how payment paths get exercised without an account. And the backend is given an internal URL for a model context protocol server, so the AI-facing surface is wired in the default stack. ## The requirements say pnpm 9 and the manifest pins 10.26.2 The requirements list is short and specific: Docker, Node.js 20 or above checked with a version command, pnpm 9 or above checked with a version command, and WSL 2 on Windows. It recommends a version manager for Node and, optionally, Python 3.11 with a modern Python package manager, needed only if you want to run the sync command in the backend or workers packages outside a container. Then the root manifest, which names the package manager down to the patch: 10.26.2. So the documented floor and the enforced version are a full major apart, and the second one wins, because the package manager field is what actually selects the version. The rest of that manifest is worth reading. The package is named with a two-letter name, marked private, licensed MIT, and its version matches the newest release exactly. And it has no runtime dependencies at all. Everything it needs is a development dependency, including two internal packages that point at the workspace rather than at a registry. That last point is the one to hold on to. The root manifest is a toolchain description, not a dependency list, so it tells you nothing about what the application itself requires. The real dependency surface is in the workspace packages. ## The starter CLI is compiled on every install Two scripts are defined at the root and both run automatically. The prepare hook installs the git hooks. The postinstall hook runs a node script inside the internal CLI package to build it. So the command you use to start a new project is compiled during dependency installation, every time, on every machine, including CI. That is a deliberate trade: it means there is no published CLI binary to keep in step with the template, and it also means a broken build of the CLI fails your install rather than your first command. The same CLI appears in the manifest's development dependencies as a workspace package pinned to the workspace version, alongside a second internal package for shared code. Both use the workspace protocol rather than a version range, which is what tells the package manager to link them locally instead of fetching them. Two smaller details in the same file. The hook installation is spelled in the older long form rather than the current one, and the package manager version pin means anyone without that exact version installed will have their package manager fetch it, which is convenient locally and one more thing to provision in a container image. ## The monorepo toolchain is pinned, the browser types are not The development dependency list is long enough to tell you what kind of project this is, and a few entries in it are worth pulling out. The build system is a monorepo orchestrator, and every one of its ten packages is pinned to the same exact patch version rather than a range. That is the right call for a tool that has to keep ten plugins in step. Then the graph query layer, with a version 4 client and a code generator, alongside a Babel preset and two competing JavaScript toolchains, which is what a project that builds both a modern bundle and a legacy bundle ends up carrying. There is a plugin for the legacy bundle, which confirms that is the reason. The type definitions are where the version skew shows. Node's types are pinned to one patch of the version 20 line, React's types are on a modern major, and the router's types are still on the 5.x line from before the current router generation. Reading those three numbers together tells you the router surface in the app is the older API, whatever the runtime code uses. Testing is six packages from one library plus the test runner, which is the standard shape for a project that tests components, hooks and user interaction separately. ## Three compose files, a Bitbucket pipeline and a hosted platform manifest The repository root is where the delivery story is visible, and it is broader than one hosting target. There is the default compose file plus three named variants for local development, continuous integration and production. There is a Bitbucket pipelines file sitting next to the GitHub templates, so the project expects to be built by two different pipeline systems. And there is a deployment manifest for a managed application platform, alongside the AWS-based architecture the page describes. Three env files are committed as templates: a shared one, a test one and an example for a virtual private server. Those are the files the getting-started instructions tell you to copy from. Then the tooling files. There is a monorepo orchestrator config, a version-control-driven release script, a patch directory, a Tailwind preset for the workspace, a base TypeScript config, an editor config for the linter alongside a compatibility shim for the older config format, a formatter config with an import-sorting plugin, and a Jest preset plus config. There is also a husky directory with a lint-staged config, which is what makes formatting and linting run on staged files rather than in a pipeline job. And three directories that are not about the product: two editor agent configuration directories and an agent instruction file, which tells you the project is developed with AI assistants configured in the repository rather than on each machine. ## The authentication list is longer than a starter kit usually ships The feature section is a set of collapsible blocks, and the first one is the one that survived onto the visible page. Authentication and authorization covers four things. User registration and login, including two named OAuth providers. WebAuthn passkeys for passwordless authentication. Enterprise single sign-on over two protocols, with a directory sync standard alongside it. And the basics for authorization: a name, a surname and a role. That combination is unusual for a template. Two social logins and passkeys are common; enterprise federation with directory provisioning is what an organisation buys separately, and putting it in the starter means the directory sync code is yours to maintain rather than something you integrate later. Each block links to its own page in the documentation, and the page is cut off partway through the auth block, at the user role line. So the visible page documents one of the feature areas in detail and gestures at the rest. The block structure is itself a choice worth noting: the features are presented as a nested list of disclosures rather than a table, so the page reads as a summary with the detail one click away in the documentation. ## Four ways to start, and one rule about the target directory There are three one-line ways to create a new project, one per package manager, and each takes the directory you want: ```bash npm init saas-boilerplate PATH ``` ```bash pnpm create saas-boilerplate PATH ``` ```bash yarn create saas-boilerplate PATH ``` Two notes follow. Replace the placeholder with the directory name you want, and the target directory must be empty or non-existent, because the tool creates it. That second rule is the kind of thing a starter tool should refuse to guess about, and it is stated as a warning rather than discovered. If you would rather not use the tool, the manual path is to clone the repository and follow the getting-started guide, and on Windows the subsystem for Linux is mandatory for both installing dependencies and running the application. The run surface is one command per concern, all under the same prefix: one to start the backend and the web app together, one for each of them alone, one for the documentation server, and one to stop everything. That is a small vocabulary, and it is the vocabulary you will type for the rest of the project's life. ## Conclusion saas-boilerplate suits a team that wants a subscription product's plumbing already written, including authentication, an admin panel, background workers and a local mail catcher, and that would rather delete the parts it does not need than assemble them. Three things to check before you build on it. Replace the committed credentials before the first run, because the documentation tells you to start from the shared template. Decide whether the admin panel's subdomain of localhost resolves on your machine, since that entry is the one that does not work everywhere. And note that the root package has no runtime dependencies at all, which is a sign of how much of the stack lives in the workspace rather than in the manifest you can read quickly. ## FAQ ### what is saas boilerplate This one is a complete starter kit for subscription products in React with a Django backend and an AWS-based architecture, including a frontend, a backend API, an admin panel and workers, with continuous deployment and multiple environments for pipeline stages. It is MIT licensed and its newest release is 5.0.0 from March 2026. ### What runs locally after you start saas-boilerplate? Six services: the web app on port 3000, the backend API on 5001 with Django and GraphQL, the admin panel on a subdomain of localhost at 5001, a mail catcher on 1080, the documentation server on 3006 and a workers trigger server on 3005. The documented first steps are to create an account, read the verification email from the mail catcher, and log into the admin panel with credentials from your env file. ### How do I start a new project from saas-boilerplate? With a starter command, one per package manager, each taking the directory you want: an init command under npm, a create command under pnpm or yarn. The target directory must be empty or non-existent because the tool creates it. Otherwise clone the repository and follow the manual setup guide in the documentation. ### What are the requirements for running saas-boilerplate? Docker, Node.js 20 or above, pnpm 9 or above, and the Linux subsystem on Windows. Optionally Python 3.11 with a modern Python package manager if you want to run the sync command in the backend or workers packages outside a container. The root manifest pins a specific package manager version above the documented floor. ### How does saas-boilerplate handle payments and email locally? The compose file runs a mock of the payment provider's API alongside the application, and a mail catcher captures all outgoing email locally, so signup verification and payment paths can be exercised on a laptop. The same file sets the database user, password and name, and the backend's cloud access keys, to literal placeholders that the documentation expects you to replace from the shared env templates. ### Which authentication methods does saas-boilerplate include? The visible feature list covers registration and login with two named OAuth providers, WebAuthn passkeys for passwordless login, enterprise single sign-on over two protocols with a directory sync standard alongside, and basic user data including a role for authorization. Each feature area links to its own documentation page. ## Sources - [apptension/saas-boilerplate on GitHub](https://github.com/apptension/saas-boilerplate) - [License: MIT](https://github.com/apptension/saas-boilerplate/blob/master/LICENSE) - [Project website](https://apptension.com/saas-boilerplate) - [README](https://github.com/apptension/saas-boilerplate/blob/master/README.md) - [Releases](https://github.com/apptension/saas-boilerplate/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apptension-saas-boilerplate