三条命令跑起一个 SaaSSaaS Boilerplate 架构深度指南【免费下载链接】saas-boilerplateSaaS 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!项目地址: https://gitcode.com/gh_mirrors/saa/saas-boilerplate自己搭 SaaS第一关往往不是业务功能而是多租户、计费、后台任务这些跟核心卖点无关却绕不开的轮子。SaaS Boilerplate 是一套基于 React、Django 和 AWS 的开源 SaaS 启动套件把这些基建默认配齐让你第一天就写业务逻辑。第一个界面出来之前你要先造多少轮子先算一笔账。注册登录、租户切换、订阅计费、事务邮件、管理后台、部署流水线——每个 SaaS 都需要每个都得重新写一遍而且每一样都容易在细节上翻车支付状态没同步、租户 A 看到了租户 B 的数据。等你把这些写完产品真正有辨识度的部分还没动工。这套启动套件要解决的就是这件事把这些「人人都要写」的代码变成开箱即用的起点。它到底是模板还是一个完整团队一句话定位它不是只给你目录骨架的脚手架而是前端、GraphQL API、Django 管理面板、异步 workers、AWS 基础设施代码、文档站和一套可运行的 demo 全部打包在一起的 SaaS 模板。区别在于你 clone 下来看到的每个功能都有生产级实现而不是一段注释。整个仓库由 NX monorepo 管着——你可以把它想成项目的中央仓库各功能库像可插拔的货架租户、支付、通知、文档各自独立成包前端后端都能按需取用取哪块不强迫你装另一块。最费工的部分它是怎么处理的挑三个最耗时的机制拆开看多租户、订阅支付、异步任务。多租户隔离怎么隔离的问题在于同一套系统服务成百上千家公司任何一条查询漏了租户条件都是数据事故。它的方案是行级隔离——共享数据库业务表都带租户归属但关键不在「表结构里有这个字段」而在强制点做在哪。GraphQL 的中间件在放行任何租户数据前先做成员资格校验请求里就算手改了 tenant_id 想去别人的租户偷看数据拿到的也是空。权限再叠一层 RBACowner、admin、member 三种角色加按应用注册的细粒度权限码。还有一个容易忽略的细节主键用的是 hashid 而不是自增 ID等于把车牌模糊掉你没法靠遍历 ID 猜出别家的资源。这套逻辑集中在 packages/backend/apps/multitenancy/ 目录模型、中间件、权限注册都能在这里翻到。多租户系统的模型关系Tenant、成员资格与角色权限订阅支付为什么不自己管状态问题在于你代码里记的「用户在订阅 Pro 计划」永远可能和 Stripe 那边对不上对不上的那一刻就是事故。它的思路是把真相对方让给 Stripe本地用 dj-stripe 注册一组 webhook 处理器事件来了各归各位。比如收到订阅计划取消系统会自动给这个客户挂上免费计划的新计划因为 Stripe 不允许把已取消的订阅原样复活到别的计划新增一张默认支付方式系统自动把它设为订阅扣款卡。注意你的库里根本不存卡号数据账单、退款这类操作走 Stripe dashboard 和管理后台。订阅计划选择界面不同层级与计费周期异步任务怎么做到不卡 API问题在于发邮件、同步内容、跑定时任务这类活儿如果占住请求线程接口延迟会立刻难看。做法是同一套事件代码、两套执行后端本地开发时是 Celery 加 Redis生产环境则变成 EventBridge 事件触发 AWS Lambda事件源名比如 backend.scheduler两边一致业务代码不用动。你切环境时改的是配置不是逻辑——这是它敢把「本地即生产」当卖点的原因。worker 侧代码在 packages/workers/ 目录每个 handler 都是独立函数。架构全景一张图加一棵目录树SaaS Boilerplate 完整系统架构前端、API、异步 worker 与 AWS 资源这套 React Django SaaS 架构里云资源全部由 AWS CDK 用代码定义ECS 跑容器、RDS 放数据库、S3 存文件、CloudFront 做 CDN改基础设施和改代码走同一套评审流程。目录树只需记住这几处packages/ ├── webapp/ # React 前端应用Vite TS ├── webapp-libs/ # 功能库tenants、finances、notifications 等 ├── backend/ # Django API 管理面板apps/ 下按功能分应用 ├── workers/ # 异步 worker生产为 Lambda └── internal/ ├── cli/ # pnpm saas 命令行工具 └── docs/ # 文档站源码其余脚本和配置目录知道它们在那就行日常基本不会打开。SaaS 快速上手最快 3 步跑起来环境只要求三样Docker、Node 20、pnpm 9Windows 用户先装 WSL2。Python 依赖在容器里跑不用单独折腾。git clone https://gitcode.com/gh_mirrors/saa/saas-boilerplate cd saas-boilerplate cp .env.shared .env cp packages/backend/.env.shared packages/backend/.env pnpm install pnpm saas up起来之后前端在 localhost:3000GraphQL API 在 localhost:5001Django 管理面板在 admin.localhost:5001所有事务邮件会被本地 Mailcatcherlocalhost:1080截住——你注册时收到的验证邮件就在那里不用真发出去。踩坑与进阶三件上手后才会碰到的事部署流水线长什么样本地开发时 LocalStack 在 Docker 里模拟出一整套 AWSS3、事件总线之类所以你的代码从第一天起就只对一套 SDK 接口说话上线不需要「翻译成 AWS」。提交代码后由流水线跑测试、构建镜像、经 CDK 部署到对应环境多环境dev/staging/prod用同一套栈描述、不同参数区分。CI/CD 全流程测试、构建、部署与多环境管理加一个功能要手写多少代码前端这边用 Plop 模板生成CRUD 页面、表单、弹窗、GraphQL 请求基本是填字段名出代码后端对应地写模型序列化器、schema、测试按既有模式补齐。参考范本就在 packages/backend/apps/demo/ 和前端 demo 库照着改比照着文档写快得多。性能账本在哪里数据库层面靠 ORM 的 select_related / prefetch_related 控制查询次数、Redis 缓存高频数据前端按路由做代码分割首屏只加载当前页面需要的功能库接口限流统一收在 backend/common/ratelimiting/ 里新接口挂上去就行。接下来读什么SaaS Boilerplate 的价值不在于「功能多」而在于它把 SaaS 里最容易被低估的横切关注点——租户边界、计费状态机、异步边界——都提前做成了有测试、有文档的实现你接手的是决策而不是坑。完整文档在 packages/internal/docs/docs/从 getting-started 读到 features 即可覆盖上文所有机制想抄写法就看 packages/backend/apps/demo/这是官方留给你「照着改」的示例应用worker 与部署细节见 packages/workers/README.md 和根目录的 bitbucket-pipelines.yml【免费下载链接】saas-boilerplateSaaS 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!项目地址: https://gitcode.com/gh_mirrors/saa/saas-boilerplate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
三条命令跑起一个 SaaSSaaS Boilerplate 架构深度指南【免费下载链接】saas-boilerplateSaaS 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!项目地址: https://gitcode.com/gh_mirrors/saa/saas-boilerplate自己搭 SaaS第一关往往不是业务功能而是多租户、计费、后台任务这些跟核心卖点无关却绕不开的轮子。SaaS Boilerplate 是一套基于 React、Django 和 AWS 的开源 SaaS 启动套件把这些基建默认配齐让你第一天就写业务逻辑。第一个界面出来之前你要先造多少轮子先算一笔账。注册登录、租户切换、订阅计费、事务邮件、管理后台、部署流水线——每个 SaaS 都需要每个都得重新写一遍而且每一样都容易在细节上翻车支付状态没同步、租户 A 看到了租户 B 的数据。等你把这些写完产品真正有辨识度的部分还没动工。这套启动套件要解决的就是这件事把这些「人人都要写」的代码变成开箱即用的起点。它到底是模板还是一个完整团队一句话定位它不是只给你目录骨架的脚手架而是前端、GraphQL API、Django 管理面板、异步 workers、AWS 基础设施代码、文档站和一套可运行的 demo 全部打包在一起的 SaaS 模板。区别在于你 clone 下来看到的每个功能都有生产级实现而不是一段注释。整个仓库由 NX monorepo 管着——你可以把它想成项目的中央仓库各功能库像可插拔的货架租户、支付、通知、文档各自独立成包前端后端都能按需取用取哪块不强迫你装另一块。最费工的部分它是怎么处理的挑三个最耗时的机制拆开看多租户、订阅支付、异步任务。多租户隔离怎么隔离的问题在于同一套系统服务成百上千家公司任何一条查询漏了租户条件都是数据事故。它的方案是行级隔离——共享数据库业务表都带租户归属但关键不在「表结构里有这个字段」而在强制点做在哪。GraphQL 的中间件在放行任何租户数据前先做成员资格校验请求里就算手改了 tenant_id 想去别人的租户偷看数据拿到的也是空。权限再叠一层 RBACowner、admin、member 三种角色加按应用注册的细粒度权限码。还有一个容易忽略的细节主键用的是 hashid 而不是自增 ID等于把车牌模糊掉你没法靠遍历 ID 猜出别家的资源。这套逻辑集中在 packages/backend/apps/multitenancy/ 目录模型、中间件、权限注册都能在这里翻到。多租户系统的模型关系Tenant、成员资格与角色权限订阅支付为什么不自己管状态问题在于你代码里记的「用户在订阅 Pro 计划」永远可能和 Stripe 那边对不上对不上的那一刻就是事故。它的思路是把真相对方让给 Stripe本地用 dj-stripe 注册一组 webhook 处理器事件来了各归各位。比如收到订阅计划取消系统会自动给这个客户挂上免费计划的新计划因为 Stripe 不允许把已取消的订阅原样复活到别的计划新增一张默认支付方式系统自动把它设为订阅扣款卡。注意你的库里根本不存卡号数据账单、退款这类操作走 Stripe dashboard 和管理后台。订阅计划选择界面不同层级与计费周期异步任务怎么做到不卡 API问题在于发邮件、同步内容、跑定时任务这类活儿如果占住请求线程接口延迟会立刻难看。做法是同一套事件代码、两套执行后端本地开发时是 Celery 加 Redis生产环境则变成 EventBridge 事件触发 AWS Lambda事件源名比如 backend.scheduler两边一致业务代码不用动。你切环境时改的是配置不是逻辑——这是它敢把「本地即生产」当卖点的原因。worker 侧代码在 packages/workers/ 目录每个 handler 都是独立函数。架构全景一张图加一棵目录树SaaS Boilerplate 完整系统架构前端、API、异步 worker 与 AWS 资源这套 React Django SaaS 架构里云资源全部由 AWS CDK 用代码定义ECS 跑容器、RDS 放数据库、S3 存文件、CloudFront 做 CDN改基础设施和改代码走同一套评审流程。目录树只需记住这几处packages/ ├── webapp/ # React 前端应用Vite TS ├── webapp-libs/ # 功能库tenants、finances、notifications 等 ├── backend/ # Django API 管理面板apps/ 下按功能分应用 ├── workers/ # 异步 worker生产为 Lambda └── internal/ ├── cli/ # pnpm saas 命令行工具 └── docs/ # 文档站源码其余脚本和配置目录知道它们在那就行日常基本不会打开。SaaS 快速上手最快 3 步跑起来环境只要求三样Docker、Node 20、pnpm 9Windows 用户先装 WSL2。Python 依赖在容器里跑不用单独折腾。git clone https://gitcode.com/gh_mirrors/saa/saas-boilerplate cd saas-boilerplate cp .env.shared .env cp packages/backend/.env.shared packages/backend/.env pnpm install pnpm saas up起来之后前端在 localhost:3000GraphQL API 在 localhost:5001Django 管理面板在 admin.localhost:5001所有事务邮件会被本地 Mailcatcherlocalhost:1080截住——你注册时收到的验证邮件就在那里不用真发出去。踩坑与进阶三件上手后才会碰到的事部署流水线长什么样本地开发时 LocalStack 在 Docker 里模拟出一整套 AWSS3、事件总线之类所以你的代码从第一天起就只对一套 SDK 接口说话上线不需要「翻译成 AWS」。提交代码后由流水线跑测试、构建镜像、经 CDK 部署到对应环境多环境dev/staging/prod用同一套栈描述、不同参数区分。CI/CD 全流程测试、构建、部署与多环境管理加一个功能要手写多少代码前端这边用 Plop 模板生成CRUD 页面、表单、弹窗、GraphQL 请求基本是填字段名出代码后端对应地写模型序列化器、schema、测试按既有模式补齐。参考范本就在 packages/backend/apps/demo/ 和前端 demo 库照着改比照着文档写快得多。性能账本在哪里数据库层面靠 ORM 的 select_related / prefetch_related 控制查询次数、Redis 缓存高频数据前端按路由做代码分割首屏只加载当前页面需要的功能库接口限流统一收在 backend/common/ratelimiting/ 里新接口挂上去就行。接下来读什么SaaS Boilerplate 的价值不在于「功能多」而在于它把 SaaS 里最容易被低估的横切关注点——租户边界、计费状态机、异步边界——都提前做成了有测试、有文档的实现你接手的是决策而不是坑。完整文档在 packages/internal/docs/docs/从 getting-started 读到 features 即可覆盖上文所有机制想抄写法就看 packages/backend/apps/demo/这是官方留给你「照着改」的示例应用worker 与部署细节见 packages/workers/README.md 和根目录的 bitbucket-pipelines.yml【免费下载链接】saas-boilerplateSaaS 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!项目地址: https://gitcode.com/gh_mirrors/saa/saas-boilerplate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
