[Github] Kaneo – 可自托管并接入 MCP 的开源项目管理工具

Kaneo 是一款面向产品与开发团队的开源项目管理工具，核心形态是项目、Backlog、看板/List、任务与协作，并把 GitHub 同步和 MCP 接口放进同一套自托管系统。它更适合愿意维护 Docker、PostgreSQL、域名和备份的小团队；如果你要的是免运维 SaaS、成熟企业治理或文档数据库一体化，Kaneo 未必比现有平台省事。截至 2026 年 9 月 1 日，本文依据官方仓库与文档核对，未进行生产环境部署或恢复演练。

它解决什么

Kaneo 的判断重点不是“功能有没有 Jira 多”，而是团队能否用更少的界面完成从 Backlog 到交付的主路径。官方功能指南把日常使用拆成创建工作区与项目、在 Board/List 中规划任务、维护 Backlog、团队协作、配置工作流和管理标签。对不需要复杂报表与多层流程的产品团队，这种收敛能减少维护工具本身的时间。

界面同时保留项目、成员、邀请、筛选、负责人、优先级和状态列，说明它不是个人待办清单，而是有工作区边界的团队任务系统。这里的代价也很清楚：当组织需要跨项目资源规划、精细审计、采购级 SLA 或大量第三方插件时，不能只凭“更简洁”就假定 Kaneo 已覆盖。

先选部署路径

官方提供的入口适合不同运维能力。选择时先看谁负责域名、HTTPS、数据库备份和升级，而不是只比较启动命令长短。

按官方 Docker Compose 文档，标准组合包含 ghcr.io/usekaneo/kaneo:latest 和 PostgreSQL 16，浏览器入口默认映射到 5173 端口。最少需要设置 KANEO_CLIENT_URL、数据库用户名与强密码，以及不少于 32 字符的 AUTH_SECRET。官方示例使用 openssl rand -hex 32 生成随机值；不要把示例密码或真实密钥写进仓库。

上线前先补齐

“容器能启动”只代表服务进程存在，不等于已经适合团队使用。正式接入任务数据前，至少完成下面的检查：

1. 固定访问地址：先确定域名与 HTTPS，再把 KANEO_CLIENT_URL 写成最终外部地址；更换地址后重新检查登录回调、MCP 和 GitHub webhook。
2. 保护数据库：保留 PostgreSQL 持久卷，建立独立备份并做一次可读性检查。升级前先备份数据库；没有恢复演练时不要把“有备份”等同于“可以恢复”。
3. 决定上传能力：Kaneo 不配置对象存储也能运行，但任务描述和评论中的文件上传不可用。需要上传时再接入 MinIO、AWS S3、Cloudflare R2 或其他 S3 兼容后端，并让存储桶保持私有。
4. 收紧注册：根据团队入口设置访客、公开注册、密码注册或 SSO。启用 SSO-only 前，先确认既有账号已经完成邮箱验证，避免把管理员锁在系统外。
5. 准备回滚：记录当前镜像、Compose 与环境变量版本，保留数据库备份；升级后若认证、迁移或任务读写异常，先停止继续写入，再按 Release 和迁移文档评估回退。不要在没有数据副本时直接试降级。

本文没有替你执行这些操作。生产环境还应根据反向代理和网络边界核对 TRUSTED_PROXIES；官方明确提醒，只能信任自己控制的代理地址，否则客户端可伪造转发头并影响限流与会话记录。

MCP 怎么接

Kaneo 提供两条 MCP 路径。每个实例内置 Streamable HTTP 端点 /api/mcp，适合能直接连接 HTTP MCP 的客户端；首次连接会跳转到 Kaneo，由用户登录并明确授权。另一条是官方 @kaneo/mcp stdio 包，适合需要本地进程的客户端，但官方文档要求 Node.js 24 或更高版本，并通过设备授权完成登录。

两条路径都能管理工作区、项目、任务、评论、标签和工时等对象。AI 客户端因此可以创建、移动或删除任务，这不是只读搜索插件。接入前应使用专门账号或最小工作区权限，先在测试项目里验证 whoami、列出项目和读取任务，再逐步开放写操作。自动化要先调用项目列和成员列表解析有效 ID，不能凭名称猜测状态或负责人。

GitHub 集成成本

Kaneo 的 GitHub 集成可以在任务与 Issue 之间同步，并根据分支 push、PR 打开或合并更新任务状态。它依赖 GitHub App，而不是把个人访问令牌随手填进环境变量。根据官方设置文档，Issues 需要读写权限；Pull Requests、Metadata 和 Contents 使用读取权限；同时要订阅 Issues、Issue comments、Pull requests 和 Push 事件，Webhook 地址还必须能由 GitHub 通过 HTTPS 访问。

这套集成对研发团队有价值，但权限面比普通看板更大。建议只把 App 安装到确实需要同步的仓库，私钥与 webhook secret 放入密钥管理系统并定期轮换。GitHub 登录和仓库同步是两套配置：前者使用 OAuth App，后者使用 GitHub App，不能把两组 Client ID、私钥和 webhook 变量混为一谈。

谁适合采用

• 适合：需要看板、Backlog、任务协作与 GitHub 状态联动，同时希望把数据库和服务留在自有基础设施中的小型产品或研发团队。
• 适合：希望让 Cursor、Claude 或其他 MCP 客户端在明确授权下管理项目任务，并愿意先建立权限与审计边界的团队。
• 暂不适合：没有人负责备份、升级、域名、HTTPS 和故障恢复，却把“自托管”理解为零维护的团队。
• 需要另选：主要需求是多人文档、知识库和灵活数据库，而任务流只是附带功能，可以先查看 Notion；需要重型企业治理时，则应先列出审批、审计、报表和 SLA 硬条件再比较。

项目状态

截至 2026 年 9 月 1 日，Kaneo 仓库页面显示约 8,869 Stars、743 Forks，采用 MIT License；最新正式 Release 为 v2.22.0，发布于 2026 年 8 月 21 日，核验当天仍有新提交和开放 Issue。它可以被判断为近期有维护活动，但这不等于每个版本都适合直接升级生产环境。

上线前应查看当前 Release、Compose 文件、环境变量文档和迁移说明。Stars、Forks、版本号、MCP 协议兼容范围与部署变量都会变化，不能把本文的核验快照当作长期不变的保证。

相关链接

• 项目官网：https://kaneo.app/
• 官方文档：https://kaneo.app/docs/core
• Kaneo GitHub 仓库
• Docker Compose 文档：https://kaneo.app/docs/core/installation/docker-compose
• MCP 文档：https://kaneo.app/docs/core/integrations/mcp
• Release：https://github.com/usekaneo/kaneo/releases