📌 项目地址：usekaneo/kaneo | ⭐ 4,882 颗星 | 🔧 TypeScript | 📜 未标注
受够了“大而全”之后，Kaneo 想做减法
团队项目管理工具这个赛道已经很拥挤了。Jira、Linear、Asana、ClickUp 各有拥趸，但一个普遍的问题是：功能越来越臃肿。通知、看板、自动化、OKR、时间线、报表……这些功能堆叠在一起，反而让“管理项目”这件事变成了“管理工具”。团队每天要处理大量与应用相关的噪音，而不是推进实际的工作。
Kaneo 的出发点很直接：承认大多数工具的问题不是功能太少，而是功能过多。它选择做减法，只保留真正解决问题的核心功能，界面保持干净，聚焦在工作内容而不是工具本身。听起来像是普通的口号，但 Kaneo 用“自托管”和“MIT 许可”来兑现它的承诺——你的数据、你的规则、你的节奏，不被平台绑定。
两种方式跑起来：一条命令，或者一份 compose 文件
Kaneo 提供了两条启动路径，各有侧重。如果你想要最省事的部署，drim 是官方推荐的一键工具：
curl -fsSL https://assets.kaneo.app/install.sh | sh
drim setup
执行完这两条命令，Kaneo 会自动配置 HTTPS、数据库和所有依赖服务，直接跑起来。这个方案适合想要快速上生产，又不想手动折腾环境的场景。
如果你想先本地试试，或者希望看清楚它到底依赖什么，Docker Compose 是更透明的方式。README 给出了完整的 compose.yml：
services:
postgres:
image: postgres:16-alpine
env_file:
- .env
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -U kaneo -d kaneo"]
interval: 10s
timeout: 5s
retries: 5
kaneo:
image: ghcr.io/usekaneo/kaneo:latest
ports:
- "5173:5173"
env_file:
- .env
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped
volumes:
postgres_data:
使用方式：保存为 compose.yml，复制 .env.sample 为 .env，取消 KANEO_CLIENT_URL=http://localhost:5173 的注释，设置 POSTGRES_PASSWORD= 和 AUTH_SECRET=，然后：
docker compose up -d
浏览器打开 http://localhost:5173 就能看到界面。注意，在 Compose 网络中，Kaneo 容器通过服务名 postgres 访问数据库。这个细节很重要——如果你打算在宿主机上直接跑 API 而不是用容器，连接方式会不一样。
整个配置只用到了两个容器：一个 PostgreSQL 16，一个 Kaneo 本体（镜像来自 ghcr.io）。意味着这是一个轻量的、前后端打包在一起的单容器应用，不是微服务集群。
为什么选 Kaneo，而不是继续用 Jira 或 Linear
这里不打算做全面的功能对比表——那是无意义的。真正值得说的是 Kaneo 的取舍逻辑。
市场上主流的项目工具大多默认一个前提：你的团队需要“工作流管理”。于是它们提供数不清的状态、字段、权限、自动化规则，甚至自定义工作流引擎。但这套体系是有学习成本的，而且它隐隐地将项目经理的需求放在了执行者之上。Kaneo 的立场不同：它假设你需要的只是一个清晰的看板，任务状态能表达就行，其他都是噪音。
对比 Linear 这类追求高效交互的商业产品，Kaneo 的差异在于“所有权”。Kaneo 是自托管的，代码在 GitHub 上，MIT 许可。不会因为订阅到期导致数据无法导出，不会有厂商锁定，也不会突然因为商业策略改变而调整定价或功能边界。
这也意味着，如果你恰好是那种觉得“现有工具已经够用，但我想要一个能掌控全局、能改源码的替代品”的团队，Kaneo 是少数定位如此明确的选项。
一些实际的考量
第一个要注意的是许可证。Kaneo 使用 MIT 许可——这是相当宽松的开源许可，允许商用、修改和分发，只需要保留版权声明即可。这降低了团队引入它的法律风险。
第二个是数据安全。自托管的好处是数据完全由你掌握，但这同时意味着安全责任也转移到了你自己的运维团队身上。数据库密码、鉴权密钥（AUTH_SECRET)、HTTPS 证书，这些都需要你自己负责。如果团队没有运维能力，建议先用 drim 进行部署，它帮你处理了这些底层细节。
第三个是项目的成熟度。4882 个 Star 不算少，但和 Jira 这类拥有数百万人使用的商业产品仍然不是一个量级。Kaneo 的目标用户更像是小型团队、独立开发者、或者对数据主权有强烈要求的组织。如果你的团队需要一个多级权限管理、复杂报表、资源跨项目调度等企业级功能，Kaneo 大概率不是你要找的工具——它就是故意的。
另外要注意的是，目前 Kaneo 部署到生产环境后，其自动更新机制并不明确。镜像 tag 使用的是 latest，如果你担心不可控的更新影响稳定性，建议固定镜像版本，并建立自己的发布流程。
如果你想进一步探索
Kaneo 的功能细节和架构设计在官方文档中有更完整的介绍（https://kaneo.app/docs/core）。如果你对它感兴趣，建议先跑一下 Docker Compose 那个流程，五分钟之内就能看到真实界面。也可以从 GitHub 仓库研究它的代码结构，毕竟它是 MIT 许可，你可以自由阅读和修改。
如果你想参与社区或者和作者交流，官方 Discord 在 https://discord.gg/rU4tSyhXXU。如果你觉得这个项目对你的工作有帮助，也可以考虑通过 GitHub Sponsors 支持作者继续开发。
最后总结：Kaneo 是一个有明确态度、不强求适应所有人、并在自托管场景下做出真实价值的项目。它可能不会成为另一个 Jira——它也没打算成为。