Multi-tenant SaaS boilerplate built on FastAPI and Next.js, enabling rapid development and deployment of production-ready applications. It features per-organization data isolation, role management, and extensive feature toggling via environment variables, facilitating a full-stack SaaS launch within a weekend.

How It Works

The architecture uses a FastAPI backend (Authx, SQLAlchemy) and Next.js frontends. Multi-tenancy enforces data isolation via an org_id on tenant rows. JWTs are dynamically scoped to the active organization. Role-based access control (Owner, Admin, Member) maps to Authx scopes with wildcard support. API keys provide organization-specific access.

Quick Start & Requirements

Prerequisites: uv (>= 0.5), bun (>= 1.3), Docker. Recommended setup: clone repo, copy .env.example to .env, then make stack-build, make stack-up, make stack-create-admin. Local dev: make bootstrap, make up, make migrate, then make dev-backend, make dev-frontend, make dev-admin in separate terminals. Key URLs: gateway (http://localhost:8080), backend API docs (http://localhost:8000/docs), tenant app (http://localhost:3000), admin portal (http://localhost:3001).

Highlighted Details

• Feature Flags: Optional modules (OAuth, email, Stripe, AI/LLM Gateway, observability, audit log, rate limiting) are gated by FEATURE_* env vars, incurring zero runtime cost when disabled.
• Multi-tenancy: Shared database/schema with org_id on tenant rows for strict data isolation. Org switching dynamically updates JWT claims/scopes.
• Role-Based Access Control: Granular permissions via roles (Owner, Admin, Member) mapped to Authx scopes with wildcard support (e.g., org:*).
• API Keys: Organization-specific API keys with scoped permissions, validated via X-API-Key.

Maintenance & Community

The provided README does not detail specific contributors, sponsorships, or community channels (e.g., Discord, Slack).

Licensing & Compatibility

Licensed under MIT, generally permitting commercial use and integration into closed-source projects without significant restrictions.

Limitations & Caveats

Frontend feature visibility requires matching NEXT_PUBLIC_FEATURE_* env vars, baked into Docker builds at compile time. Custom clients integrating with cookie-based auth must implement the X-CSRF-TOKEN header. As a boilerplate, it requires further development for specific product needs.