# Nextacular: a multi-tenant SaaS starter kit on Next.js, Prisma and Stripe

> Nextacular is an open-source starter kit for full-stack multi-tenant SaaS products, shipping authentication, teams, workspaces, billing, email, custom domains and a multi-tenancy approach out of the box. The tension to understand before adopting it is that the README still advertises a 2022 dependency set while the package manifest has moved on, and the release tags stopped in 2022.

**nextacular/nextacular** — An open-source starter kit that will help you build full-stack multi-tenant SaaS platforms efficiently and help you focus on developing your core SaaS features. Built on top of popular and modern technologies such as Next JS, Tailwind, Prisma, and Stripe.

- Repository: https://github.com/nextacular/nextacular
- Website: https://nextacular.co
- Stars: 1,396 · Forks: 243
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nextacular-nextacular

## What the kit gives you before you write any feature code

The pitch is stated plainly: an open-source starter kit that helps you build full-stack multi-tenant SaaS platforms efficiently so you can focus on your core features. The list of what is packaged out of the box is the list of things every SaaS product ends up building and every SaaS product gets subtly wrong. That is authentication, billing and payment, the database, email, custom domains, multi-tenancy, workspaces, and teams. The outstanding features list repeats the same set with more detail: database integration with Prisma over SQL and PostgreSQL, a multi-tenancy approach, a landing page, billing and subscription, design components that are mobile ready, SEO support, developer experience, and email handling. Read as a whole, it is a decision about what a multi-tenant product is made of, and the kit is that decision already taken for you. There is a live demo at demo.nextacular.co and the documentation lives at docs.nextacular.co, with a quick start page that is the documented first step for a new user.

## The README dependency list and the manifest disagree

Here is the first thing to sort out, and it is the kind of thing that costs an afternoon if you ignore it. The README's tech stack section pins Next.JS at 13.1.0 with React 18.2.0, Tailwind CSS at 3.1.8, Prisma at 4.4.0, and lists Headless UI 1.7.7, Hero Icons 2.0.12, Date FNS 2.29.3, Express Validator 6.14.2, Micro 9.4.1, Next Themes 0.2.1, Nodemailer 6.8.0, React Copy to Clipboard, React Google Analytics, React Hot Toast, React Top Bar Progress Indicator, Slugify, Stripe 10.13.0, SWR 1.3.0 and Validator 13.7.0. The package manifest in the same repository says something else entirely: the version is 1.4.2, the engines field requires Node 22, Next is at 13.5.11, Prisma client at 6.19.3, Tailwind is not listed as a dependency at all but as a configuration, i18next and react-i18next are present, zod is there for validation, and Nodemailer is at 7. The README describes a 2022 kit and the manifest describes a later one. Trust the manifest, and expect the README to be stale.

## Local development runs three containers, not just Next.js

The package scripts show a developer experience that has grown past a single dev server. The three scripts you need first are the Next.js ones, and the manifest lists them plainly:

```json
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
```

Underneath them sits a local stack. There is a compose file at the repository root with three services, and the scripts manage them as a set. The database is a postgres:16-alpine container named nextacular-postgres, with a healthcheck that runs pg_isready against the configured user and database every five seconds, and a named volume postgres-data for the data directory. Mail is handled by a mailpit container with SMTP on 1025 and a web interface on 8025, configured to accept any SMTP credentials and to allow insecure mail, which is exactly what a local mail catcher needs so that magic link emails never leave your machine. The third service is adminer, a database admin UI on 8080, set to depend on postgres being healthy. The scripts that drive all of this are in the package manifest too:

```json
    "db:up": "docker compose up -d postgres mailpit adminer",
    "db:down": "docker compose down",
    "db:reset": "docker compose down -v && docker compose up -d postgres && npx prisma migrate deploy && npx prisma db seed",
    "db:logs": "docker compose logs -f postgres",
    "db:studio": "prisma studio",
```

That db:reset command is the one to understand, because it destroys the volume and re-runs the migrations and the seed, and the seed is written in TypeScript and executed through tsx. If you have local data, it is gone.

## The environment file tells you what the app refuses to boot without

There is a .env.sample at the repository root, and it is unusually well annotated, which makes it the best documentation in the repository. The file states that the app will not start without the required values. Three of them are mandatory, and the sample lines for them are these:

```bash
APP_URL=http://localhost:3000
NEXTAUTH_SECRET=replace-me-with-an-openssl-rand-base64-32-value
DATABASE_URL=postgresql://nextacular:nextacular@localhost:5432/nextacular
```

APP_URL is the public URL of the app, which in local development is http://localhost:3000. NEXTAUTH_SECRET signs the session JWTs, and the sample tells you to generate it with openssl rand -base64 32 and warns never to reuse the placeholder in production. DATABASE_URL is the PostgreSQL connection string, and the default matches the compose file, with a note that a hosted Postgres such as Supabase, Neon or Railway can be used instead. A fourth one is conditional: SHADOW_DATABASE_URL, which Prisma Migrate needs when the main database is managed and refuses CREATE or DROP DATABASE, so the destructive migration check has somewhere else to run. The comment says exactly that, which is a detail worth reading before you point the kit at a cloud database.

## Mail and billing are each behind their own environment variables

The same .env.sample groups the rest of the configuration by what needs it, and that grouping tells you which features are optional. The email block is marked as required for magic-link authentication, with the defaults matching the mailpit service, and it notes that all outgoing email is captured at the local web interface in development. The four values are EMAIL_FROM, EMAIL_SERVER_USER, EMAIL_SERVER_PASSWORD and EMAIL_SERVICE, and the comment points at the nodemailer well-known service list for a provider, or says to leave it blank to use the SMTP host and port defaults. The Stripe block is explicitly only required if the billing and upgrade UI is in use, with the publishable key, the payments secret key and the payments signing secret all commented out, so billing is genuinely off until you turn it on. Google Analytics 4 is optional and only initialised in production builds. The Vercel block is required only when adding custom domains to a workspace, and the file says to get the project and team IDs from the dashboard. That is a clean structure: nothing is required that you do not use.

## Multi-tenancy and workspaces are the parts you will rewrite

The features that make this kit worth looking at are also the ones most likely to conflict with your own decisions. Multi-tenancy is listed as an approach rather than a mechanism, and the repository does not document in the README how isolation is enforced, so you will need to read the code and the docs to find out whether the tenant boundary is a schema convention, a connection setting, or application-level filtering in every query. Teams and workspaces sit on top of that, and a workspace is what custom domains attach to. Workspaces also mean a second level of membership, so a user can be in a team inside a workspace inside a tenant, and the shape of that model is the part of the kit with the most opinions baked in. The practical advice is to read those two areas before the rest, and to be prepared to replace them. A starter kit is a set of decisions you did not make; the ones with the deepest consequences are the ones worth revisiting first.

## Deploy to Vercel, then fill in the environment variables yourself

The deployment path is a one-click clone to Vercel, and the URL behind the Deploy button carries the list of environment variables the deployment will ask for. They are the same set described in the .env.sample: APP_URL, NEXTAUTH_SECRET, DATABASE_URL, SHADOW_DATABASE_URL, EMAIL_FROM, EMAIL_SERVER_USER, EMAIL_SERVER_PASSWORD, EMAIL_SERVICE, and NEXT_PUBLIC_VERCEL_IP_ADDRESS, which is the one you will not find in the sample file because it only matters on Vercel. The README warns that you might encounter errors after deployment and tells you to make sure the necessary environment variables are added, which is the honest framing of a one-click deploy: the click gets you a project, and the variables are still your job. The repository also has a docker-compose.yml at the root and a prisma directory, so the local stack and the deployed stack are different arrangements of the same schema, and the migrations are what you have to keep straight between them.

## Release tags stopped in 2022, the code kept moving

The version history needs stating carefully, because it affects how you judge the project. The tagged releases are v1.3.0-Beta from 2022-12-28, v1.2.0-Beta from 2022-05-11 and v1.1.0-Beta from 2022-03-12, and the repository has no releases newer than those. The last push was on 2026-05-30, and the package manifest is at version 1.4.2, so the working code is past the newest tag by a good margin and the tags themselves are all marked as beta. There is a CHANGELOG at the root, an AGENTS.md, a CLAUDE.md, a SECURITY file, a CODE_OF_CONDUCT, a CONTRIBUTING file and a docs directory, which is the profile of a project that is still worked on rather than abandoned. The MIT licence field on the repository and the statement that all code in the repository is provided under the MIT License mean you can fork and modify without worry. The reasonable reading is that this is a maintained codebase with stale release tags, and that the tags are a poor guide to what is in the repository.

## Conclusion

Nextacular suits a team starting a multi-tenant SaaS product that wants authentication, workspaces, Stripe billing and mail already connected, and that is prepared to read and rewrite the code it inherits rather than treat it as a black box. It does not suit a team that wants a starter kit matching today's dependency versions, because the pinned versions and the tagged releases disagree with the manifest. Before adopting it, read the environment variables documentation and fill in the APP_URL, NEXTAUTH_SECRET and DATABASE_URL entries, decide whether you want the multi-tenancy approach in the kit or your own, and check the last push date, 2026-05-30, against the release tags, which stop in 2022.

## FAQ

### What does the Nextacular starter kit include?

The packaged features are authentication, billing and payment, database, email, custom domains, multi-tenancy, workspaces and teams, along with a landing page, design components that are mobile ready, SEO support and Prisma integration over PostgreSQL. A live demo is published at demo.nextacular.co.

### How do I run Nextacular locally?

The package scripts include a dev script that runs the Next dev server, and a set of database scripts. The db:up script brings up postgres, mailpit and adminer through docker compose, and db:studio opens Prisma Studio.

### Which environment variables does Nextacular require to boot?

The .env.sample states that the app will not start without three of them: APP_URL, the NEXTAUTH_SECRET used by NextAuth to sign session JWTs, and DATABASE_URL. A SHADOW_DATABASE_URL is additionally required when the database is a managed one that disallows creating or dropping databases.

### Is Nextacular still maintained?

The last push was on 2026-05-30 and the package manifest is at version 1.4.2, with a CHANGELOG, SECURITY file, CONTRIBUTING guide and docs directory in the tree. The newest tagged release, however, is v1.3.0-Beta from 2022-12-28, so the tags are behind the code rather than a reliable version history.

## Sources

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

---

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