Ever Gauzy:集成ERP、CRM、HRM的开源业务管理平台
一个把 ERP、CRM、HRM 和项目管理放在一起的开源平台,区别是同时提供 Headless APIs 和员工时间追踪。
GitHub ever-co/ever-gauzy 更新 2026-09-14 分支 develop 星标 5.1K 分叉 945
TypeScript ERP/CRM/HRM Angular/NestJS Docker/Kubernetes

🧭 决策指南

适合,如果你

  • 你需要把 ERP、CRM、HRM、ATS 和 PM 放进同一套业务平台。
    README 的 “What is it” 和 “Features” 列出这些模块。
  • 你的前端使用 React/NextJs,并希望接入 Headless APIs。
    README 的 “What's New” 说明 Ever Teams 使用 React/NextJs 并连接 Ever Gauzy Platform APIs。
  • 你希望用 Docker Compose v2.20 以上快速查看演示功能。
    README 的 “Run with Docker Compose” 要求最低 v2.20,并提供 docker-compose.demo.yml。

不适合,如果你

  • 你要求未经 Alpha/testing 阶段的生产级平台。
    README 在 “Super Quick Start” 和 SaaS 链接说明中标注 Alpha version/testing mode,并要求谨慎使用。
  • 你需要高级动态报表,但不准备部署 Cube。
    README 的生产依赖说明称没有 Cube 会禁用部分高级动态报表和数据处理能力。
  • 你需要 Jitsu 提供的数据摄取和实时管道,但不部署 Jitsu。
    README 说明没有 Jitsu 时,additional analyses / real-time pipelines 的 data ingestion 会被禁用。

前置条件

  • Docker Compose 最低版本为 v2.20。
  • 生产环境 README 推荐 PostgreSQL 14 或更高版本,16.x 更推荐。
  • SQLite 是默认数据库,仅推荐测试/demo;生产可使用 PostgreSQL 或 MySQL。
  • 生产环境推荐 Kubernetes 或 Docker,并建议配置 Redis、OpenSearch、MinIO/LocalStack、Jitsu 和 Cube。
  • 生产通信应使用 HTTPS/WSS/SSL,覆盖 REST APIs、GraphQL 和 Socket.io WebSockets。

第一步命令(README 原文)

docker-compose -f docker-compose.demo.yml up

要注意

  • 演示数据库通常每日重置,不能把 demo 数据当作持久环境。
    README 的 “Demo” 说明 demo DB 在每次部署时重置,通常为每日重置。
  • 没有 Redis 时使用内存缓存,不是分布式缓存;Jitsu 仍要求 Redis。
    README 的生产依赖说明明确区分 Redis 缺失时的 in-memory caching,并指出 Jitsu 要求 Redis。
  • 没有 OpenSearch 时会退回数据库内置搜索能力。
    README 的生产依赖说明写明 OpenSearch 缺失时使用 DB built-in search capabilities。
  • README 的 Super Admin 演示账号是 [email protected] / admin。
    README 的 “Demo” 章节给出默认 Super Admin 登录邮箱和密码。

替代方案

  • Ever Teams:如果主要需要 Open Work & Productivity Platform,而不是 ERP、CRM、HRM 全套业务模块,README 提供了 Ever Teams。
    README「What's New」

材料未说明

  • README 摘要没有提供完整的 Super Quick Start 命令。
  • README 摘要没有提供生产部署所需的 CPU、内存、存储或并发规模。
  • README 摘要没有说明 TypeScript、Node.js、Angular、NestJS 和 Nx 的具体版本兼容矩阵。
  • README 摘要没有提供自动化测试覆盖率、性能基准或故障恢复指标。
  • README 摘要没有说明 Headless APIs 的认证方式、限流策略和 API 兼容性承诺。
  • README 摘要没有展开 Community Edition License 与 AGPL v3 的适用边界及企业授权条款。

💡 深度解析

6
适合 我们只想先体验 Gauzy 的 Projects、Time Tracking 和 Invoicing,不准备配置 Kubernetes;本地已经安装 Docker Compose v2.20,能否快速启动演示环境?
适合读者: 想在本地快速评估 Gauzy 的项目管理、员工工时和发票流程的 TypeScript 团队,只有 Docker Compose v2.20 或更高版本

适合,README 为这种体验场景提供了直接的 Docker Compose 演示路径,但该环境不能当作生产部署使用。

  • README 的 Run with Docker Compose 章节要求 Docker Compose 最低版本为 v2.20,与你的环境约束一致。
  • Demo 命令会使用预构建 Docker 镜像启动基础配置,README 将用途写成 Demo、explore functionality 和 quick run。
  • 演示环境提供 [email protected] / admin 的 Super Admin 账号,以及 [email protected] / 12345678 的 Employee 账号,可直接验证角色和业务流程。
  • README 同时说明 Demo 数据库通常每日重置,且镜像来自 master 分支 CI/CD,因此测试数据和版本状态不适合承载真实业务。
  • Run with Docker Compose:you need a minimum v2.20
  • Run with Docker Compose / Demo:docker-compose.demo.yml;prebuilt Docker images;Demo / explore functionality / quick run
  • Demo:Default super-admin user login ...;Employee user login ...
  • Demo:Content of demo DB resets ... usually daily;develop/master branch CI/CD
docker-compose -f docker-compose.demo.yml up
材料未说明:README 摘录中没有给出打开演示站点的实际 URL;演示镜像对应的具体版本号和与 latest master 的偏差
不适合 我们要在员工使用 Time Tracking 和 Timesheets 的情况下启用 Activity Tracking、Productivity Tracking 与 Performance Monitoring;Gauzy 是否适合直接作为绩效依据?
适合读者: 准备启用员工 Activity Tracking、Productivity Tracking 和 Performance Monitoring 的 HR 管理者,服务于使用 Time Tracking 与 Timesheets 的组织

不适合直接把这些追踪数据当作绩效结论,因为 README 只说明平台提供监控和生产力功能,没有说明数据足以代表员工绩效或满足劳动合规要求。

  • 功能列表同时包含 Time Management、Time Tracking、Activity Tracking、Timesheets,以及 Employees Performance Monitoring,说明系统能够收集相关运营数据。
  • Gauzy 面向 collaborative、on-demand 和 sharing economies,也支持员工与承包商管理;数据主体和雇佣关系可能并不单一。
  • 项目洞察明确指出,不能把时间追踪或活动监控数据直接等同于员工绩效,需要隐私边界、告知机制、绩效指标和管理规则。
  • README 的 Security 章节只讨论通信加密和漏洞披露,没有给出员工监控的保留期限、访问审计、数据删除或各司法辖区的劳动法处理方式。
  • Features:Time Management / Time Tracking / Activity Tracking / Timesheets
  • Features:Employees Performance Monitoring
  • What is it:Collaborative, On-Demand and Sharing Economies
  • 项目洞察 common_pitfalls:误将时间追踪或活动监控数据直接等同于员工绩效
材料未说明:活动数据具体采集哪些终端行为、是否支持关闭或按角色限制;数据保留、员工访问/导出/删除以及目标地区劳动法合规机制
适合 我们现有团队使用 TypeScript、NestJS 和 Angular/RxJS,但希望用自有 React/Next.js 前端接入客户、项目、工时和发票数据;Gauzy 的 Headless API 是否适合这个架构?
适合读者: 维护 TypeScript/NestJS 后端和 Angular/RxJS 前端的产品团队,计划用自有 Web 或 React/Next.js 界面接入业务能力

适合,前提是团队愿意围绕 Gauzy 的权限和业务数据模型做集成,而不是把它当作只有几个简单 CRUD 接口的服务。

  • README 在详细功能列表中直接提供 Headless APIs,并链接到 API 文档,说明展示层可以与业务平台分离。
  • 技术栈以 TypeScript 为主,后端采用 NodeJs / NestJs,前端采用 Angular、RxJS 和 Ngx-admin;这与现有 TypeScript 服务端团队的技术背景一致。
  • README 的“What’s New”还说明 Ever Teams 使用 React、NextJs、ReactNative 和 Expo,并连接到 headless Ever Gauzy Platform APIs,证明非 Angular 客户端是明确的使用方向。
  • 但 API 的认证、权限映射、分页、幂等、事件一致性和版本兼容策略没有在提供的 README 中展开。
  • Features:Headless APIs
  • Technology Stack and Requirements:TypeScript、NodeJs / NestJs、Angular / RxJS / Ngx-admin
  • What's New:Ever Teams ... React (NextJs) / ReactNative (Expo) ... connects to headless Ever Gauzy Platform APIs
材料未说明:Headless API 的完整认证方式、权限模型和版本策略;REST 与 GraphQL 的覆盖范围、速率限制和实时事件接口细节
视情况 我们想把 Gauzy 的 Headless APIs 接入闭源 SaaS,并向客户提供网络访问,但不打算公开全部修改代码;AGPLv3 和 Community Edition 许可下是否适合这样商业化?
适合读者: 要把 Gauzy 接入闭源 SaaS 的产品法务与架构负责人,计划通过 Headless API 提供客户、项目和工时能力

视情况,不能仅因项目标注开源就认定这种闭源网络集成没有许可义务,商业化前必须先厘清 Community Edition、Enterprise 和 Small Business 的适用边界。

  • 项目数据标明许可证为 GNU Affero General Public License v3.0;AGPL 对通过网络提供修改版程序的场景具有特别重要的合规影响。
  • README 的 License 章节说明:没有有效的 Enterprise 或 Small Business License agreement 时,默认是 Community Edition License。
  • README 要求进一步查看 LICENSE,并提供 compare our offering 链接,说明许可安排并不只由仓库首页的“开源”标签决定。
  • Headless APIs 确实支持将业务能力接入自有产品,但 API 集成方式、是否修改 Gauzy、是否构成衍生作品及网络服务源码提供义务,提供的 README 没有逐案解释。
  • 项目数据:license = GNU Affero General Public License v3.0
  • License 章节:The default ... license ... without a valid ... Enterprise or ... Small Business License agreement ... Community Edition License
  • License 章节:Please see LICENSE for more information on licenses;compare our offering
  • Features:Headless APIs
材料未说明:当前 LICENSE.md 对 API-only 集成、修改版网络服务和闭源前端的具体解释;商业许可的价格、适用规模、再分发条件和企业支持范围
适合 我们是一家代理机构,使用 CRM、项目管理和 HRM 流程,并且需要管理多个组织、员工工时、客户账单和多币种收入;Gauzy 是否适合作为统一业务平台?
适合读者: 经营代理机构、需要在多个组织中同时管理客户、员工、项目、工时、发票和多币种账务的运营负责人

适合,因为 Gauzy 的功能边界正覆盖代理机构从人员投入到客户收入的主要流程,但复杂财务或本地薪资仍可能需要外部系统。

  • README 将平台定位为 ERP、CRM、HRM、ATS 和项目管理平台,并明确提到 agency、studio、freelance business 和 in-house teams。
  • 功能列表包含员工/承包商费率、Time Tracking、Timesheets、Projects、Accounting、Invoicing、Billing、Payments 以及 Income / Expenses Management。
  • 它支持 Multiple Organizations Management、Departments and Teams、Roles / Permissions、Multi-currency 和 Multi-lingual,适合多实体和跨地区协作。
  • README 没有证明其满足特定国家的税务、会计或薪资法规,因此不能仅凭功能列表替代成熟财务或 payroll 系统。
  • What is it:ERP、CRM、HRM、ATS、PM 和 Employee Time-Tracking
  • Features:Employees Management、Projects / Tasks、Accounting / Invoicing、Billing、Payments
  • Features:Multiple Organizations Management、Roles / Permissions、Multi-currency、Multi-lingual
  • 项目洞察:不等同于在所有行业中替代成熟 ERP、财务系统或薪资系统
材料未说明:目标国家的税率、发票格式、会计准则和薪资合规支持范围;多组织之间的账套隔离、合并报表和跨组织权限细节
视情况 我需要为生产环境使用 PostgreSQL、Docker 或 Kubernetes,并确保 REST、GraphQL 和 Socket.io WebSockets 通过 HTTPS/WSS 加密;Gauzy 是否适合自托管?
适合读者: 负责自托管生产环境的 DevOps 工程师,计划以 PostgreSQL、Docker 或 Kubernetes 部署 Gauzy,并要求 API 和 WebSocket 使用 HTTPS/WSS

视情况:部署路径是匹配的,但它不是只启动一个应用容器就结束的轻量服务,生产运维能力会直接影响可行性。

  • README 的生产建议明确列出 PostgreSQL 或 MySQL,以及 Kubernetes、Docker,说明目标部署环境与该约束一致。
  • Docker Compose 的演示方式要求本地安装 Docker Compose v2.20 以上,可用于快速运行;但 README 将其区分为 Demo / explore functionality / quick run,而非生产配置。
  • Security 章节明确要求生产环境中客户端到后端、REST APIs、GraphQL endpoint 和 Socket.io WebSockets 使用 HTTPS/WSS/SSL 加密。
  • README 提供的内容没有完整说明生产拓扑、备份恢复、高可用、升级回滚或各组件的资源需求,因此能否满足具体 SLA 仍取决于部署设计。
  • Technology Stack and Requirements:For Production, we recommend PostgreSQL or MySQL;Kubernetes、Docker
  • Run with Docker Compose:minimum v2.20
  • Security:communications ... should be encrypted using HTTPS/WSS/SSL ... REST APIs, GraphQL endpoint, Socket.io WebSockets
  • 项目洞察:生产部署涉及数据库、缓存、搜索、对象存储、实时通信和分析等运维
材料未说明:生产环境所需 CPU、内存、数据库容量和并发指标;官方支持的备份、升级、灾备和高可用架构

✨ 核心亮点

  • ERP、CRM、HRM、ATS、PM 汇聚一体
  • 提供 Headless APIs 与多组织管理
  • Docker Compose v2.20 可启动演示环境
  • 支持 PostgreSQL、MySQL 与 SQLite

🔧 工程化

  • 覆盖 HRM、CRM、ERP、ATS、项目与任务管理
  • Headless APIs 支持 React/NextJs 的 Ever Teams
  • 包含时间追踪、发票、库存、报表和多币种

⚠️ 风险

  • README 标注 Alpha/testing,要求谨慎使用
  • SQLite 仅推荐测试/demo,生产推荐 PostgreSQL 14+
  • 缺少 Redis、Jitsu 或 Cube 会关闭部分能力
  • AGPL v3 与 Community Edition License 需核对

👥 适合谁?

  • 需要 ERP、CRM、HRM、ATS、PM 一体化的组织
  • 使用 TypeScript、Angular、NestJS 的开发团队
  • 能够部署 Docker Compose 或 Kubernetes 的团队