Jira 让你适应工具，Kaneo 让工具适应你

一个把"够用就行"做到极致的自托管看板，还内置了 MCP 服务器

前段时间要给我自己的小团队找个项目管理工具，试了一圈 Jira、Linear、Trello 之后有点崩溃------不是嫌功能少，是嫌"开始用"这件事本身太累。

Jira 那个流程我记得很清楚：先选项目类型，再配工作流方案，然后是权限方案、通知方案、字段配置......等我终于看到第一张卡片的时候，一下午没了。

后来在 GitHub 上翻到了 Kaneo 这个项目，8.9k Star，MIT 协议，自托管。它的官方描述里有句话挺有意思：

"Kaneo was built as a reaction to bloated, overcomplicated project management platforms."

翻译过来就是：这玩意儿就是冲着那些"臃肿、过度复杂"的项目管理平台去的。

我花了个周末部署试了一下，这篇文章聊聊我的实际体验。

---

先说结论：Kaneo 到底是个啥

一句话概括：一个自托管的极简 Kanban 看板工具 。

Kanban 看板：就是那种"待办 / 进行中 / 已完成"三列，卡片从左往右拖来拖去的任务管理方式，Trello 就是这个模式。

它不是什么 Jira 的替代品，更像是对 Jira 那种设计哲学的一次反叛。Jira 的思路是"把所有可能用到的需求都塞进工具里"，Kaneo 的思路是"只放真正用得上的"。

官方的口号就一句：

"All you need. Nothing you don't."

我用下来的感受是，它确实做到了------该有的功能都有，但没有一个按钮是给你"演示用"的。

基本信息：

项目	信息
GitHub Stars	8,900+
Forks	746
License	MIT
主要语言	TypeScript（React + Hono）
官网	kaneo.app
Docker 镜像	ghcr.io/usekaneo/kaneo:latest

---

它提供什么，不提供什么

这是我选工具时最关心的一点。Kaneo 的功能清单挺克制的，我列一下：

提供的：

• 看板视图（Board）+ 列表视图（List）
• 积压区（Backlog）
• 任务分配、优先级、标签、评论
• 时间记录
• 工作流自动化
• 团队成员管理
• 公开 API
• 内置 MCP 服务器（这个后面细说）

刻意不提供的：

• 复杂的权限方案（比如"这个角色能看这个字段但不能改那个字段"那种）
• 自定义问题类型层级（Jira 的 Epic / Story / Task / Sub-task 那一套）
• 第三方应用市场

说实话，作为一个带 5 人小团队的开发者，Kaneo 不提供的那些恰恰是我从来没真正用过的。Jira 那些功能对 500 人以上的大公司可能有用，但对小团队来说就是负担。

---

我最喜欢的三个点

1. Board 和 List 两个视图共享同一份数据

这个体验非常舒服。

Board 视图：就是看板，卡片按列排布，适合站会的时候看整体进度。

List 视图：就是表格，一行一个任务，适合做 Sprint 规划和批量改优先级。

很多工具这两个视图是"两套数据"，切过去之后状态对不上，或者要重新配置。Kaneo 的两个视图状态、优先级、标签是完全同步的，切换不会丢任何数据。

我平时习惯这样用：早上站会用 Board 看一眼，写周报或者梳理积压任务的时候切 List。

【建议配图】：一张对比截图，左边是 Kaneo 的 Board 视图（拖拽卡片的样子），右边是同一个项目切到 List 视图的样子，突出"同一份数据不同展示"。

2. 内置 MCP 服务器，能在 Claude / Cursor 里直接操作任务

这是 Kaneo 最让我意外的一个功能。

MCP (Model Context Protocol)：可以理解为"让 AI 工具（比如 Claude、Cursor）能调用外部服务的一套标准接口"。以前 AI 只能跟你聊天，有了 MCP，它能真的去帮你创建任务、改状态。

Kaneo 内置了一个 HTTP MCP 端点，地址是 /api/mcp。配置好之后，我可以在 Claude 对话里直接说：

• "帮我在 项目名 里创建一个任务：实现用户注册功能，优先级 P1"
• "看一下本周所有未完成的高优先级任务"
• "把 #42 任务的负责人改成 Alice"

不用打开浏览器，不用切窗口，直接在 AI 对话里就搞定了。对于我这种一天到晚泡在 Cursor 里的人来说，这个体验相当丝滑。

配置方式（Claude Desktop 为例）：

{
  "mcpServers": {
    "kaneo": {
      "command": "npx",
      "args": ["-y", "@kaneo/mcp"],
      "env": {
        "KANEO_URL": "http://localhost:5173",
        "KANEO_API_KEY": "your-api-key"
      }
    }
  }
}

Kaneo 的 MCP 支持两种接入模式：HTTP 端点（服务端内嵌，适合 Web 客户端）和 stdio 包（npx -y @kaneo/mcp，适合 Claude Desktop、Cursor 这类桌面工具）。两种模式暴露的工具集是一样的，覆盖项目、任务、标签的完整增删改查。

3. SSO 免费，不设付费墙

Kaneo 支持这些认证方式，而且自托管版本全部免费：

• 用户名 + 密码
• GitHub OAuth
• Google OAuth
• Discord OAuth
• 自定义 OIDC（企业 SSO）

OIDC：一套企业常用的单点登录标准，可以让员工用公司统一的账号登录各种内部系统。

这一点跟 Jira 的差别挺大的------Jira 的 SSO 要 Guard 或 Enterprise 订阅才能用，Kaneo 直接开放。我翻了一下他们 GitHub 的 issue 区，有用户专门提过这点，说"这才是自托管该有的样子"。

---

部署：我选的是 Docker Compose

Kaneo 提供了四种部署方式，我简单对比一下：

方式	适合谁	难度
drim CLI	生产服务器一键部署	★☆☆
Docker Compose	本地开发或小团队生产	★★☆
Coolify	用自托管 PaaS 的人	★★☆
Helm / Kubernetes	企业级集群	★★★

我选的是 Docker Compose，因为服务器上本来就跑着别的服务，直接用 compose 编排最省事。

最简方式（drim CLI）：

curl -fsSL https://assets.kaneo.app/install.sh | sh
drim setup

这个命令会自动处理 HTTPS、数据库配置和服务启动，适合直接部署到服务器上，连 Docker 都不用自己写。

Docker Compose：

# docker-compose.yml
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: kaneo
      POSTGRES_USER: kaneo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "5432:5432"

  kaneo:
    image: ghcr.io/usekaneo/kaneo:latest
    environment:
      DATABASE_URL: postgresql://kaneo:${POSTGRES_PASSWORD}@postgres:5432/kaneo
      AUTH_SECRET: ${AUTH_SECRET}
      KANEO_CLIENT_URL: http://localhost:5173
    ports:
      - "5173:5173"
    depends_on:
      - postgres

启动前先生成一个 AUTH_SECRET：

openssl rand -hex 32

然后：

docker compose up -d
# 访问 http://localhost:5173

本地开发：

git clone https://github.com/usekaneo/kaneo.git
cd kaneo
pnpm install
pnpm dev

整个部署过程我花了大概 15 分钟，包括装 Docker、拉镜像、配环境变量。对比 Jira 那种"配一下午"的体验，这个速度确实让我有点感动。

【建议配图】 ：一张终端截图，显示 docker compose up -d 之后容器启动成功的日志，旁边配上浏览器打开 localhost:5173 的 Kaneo 首页。

---

技术栈：Hono + React + PostgreSQL

我翻了一下源码结构，大致是这样：

apps/
  web/       ← React + TypeScript + Tailwind（前端）
  api/       ← Hono + TypeScript（后端）

packages/
  mcp/       ← @kaneo/mcp npm 包（MCP stdio 客户端）
  db/        ← PostgreSQL schema + 迁移

部署产物：
  ghcr.io/usekaneo/kaneo    ← 单一捆绑镜像（推荐）
  ghcr.io/usekaneo/web      ← 前端独立镜像
  ghcr.io/usekaneo/api      ← 后端独立镜像

后端用了 Hono 这个框架，我特意去了解了一下。

Hono：一个超轻量的 Web 框架，整个包大概 12KB，比 Express 轻很多。TypeScript 原生支持，而且能跑在 Node.js、Deno、Bun、Cloudflare Workers 各种运行时上。

从社区反馈来看，Hono 这两年热度涨得挺快，Kaneo 选它算是比较有技术判断力的一个决定------轻量、类型安全、跨运行时，对自托管项目来说很合适。

---

其他值得一提的功能

GitHub 和 Gitea 集成

通过 GitHub App 授权，Kaneo 可以同步 GitHub Issues：

• GitHub Issue 在 Kaneo 里能看到，状态双向同步
• 开发分支可以和任务关联，PR 合并时自动更新任务状态
• 也支持 Gitea（自托管的 Git 服务）

对我这种"产品规划和代码开发想在一个视图里管"的人来说，这个功能挺实用的。

工作流自动化

可以自定义列（Column）和自动化规则，比如：

• 任务移入 "In Review" 列时，自动通知负责人
• 截止日期临近时，自动提升优先级
• PR 合并时，自动把关联任务移到 "Done"

通知渠道

Kaneo 支持的通知渠道比我想象的多：

• Discord、Slack、Telegram
• 邮件
• ntfy、Gotify（自托管通知服务）
• Webhook（通用出站）

ntfy / Gotify：两个可以自己部署的通知服务，把消息推送到手机或桌面。对不喜欢用 Discord/Slack 的自托管玩家来说，这两个支持很贴心。

从这点能看出来，Kaneo 团队是真的懂自托管用户在想什么。

对象存储（附件）

支持 S3 兼容接口，可以接 MinIO（自托管）、AWS S3、Cloudflare R2。

---

跟 Jira 的对比

我做了个表，方便大家直观感受：

维度	Jira	Kaneo
上手时间	配置工作流、权限、通知，可能一下午	分钟级
SSO	需要 Guard/Enterprise 订阅	自托管免费
自托管授权	Data Center 年费	MIT 免费
云端用户数	按用户计费	$4/月起
MCP / AI 集成	无	✅ 内置
数据所有权	托管在 Atlassian	完全自主
适合场景	大型企业复杂工作流	小团队快速迭代

---

谁适合用 Kaneo

我总结了一下，这几类人应该会喜欢：

1. 厌倦了 Jira 配置地狱的小团队：开箱即用，分钟级上手
2. 重视数据主权的开发团队：MIT 协议，自托管，数据不经过第三方
3. AI 工具重度用户：通过 MCP 在 Claude/Cursor 里直接管任务，减少窗口切换
4. 开源爱好者和自托管玩家：Docker + Helm + Coolify 支持齐全

如果你是大公司、需要复杂的权限方案和自定义工作流，那 Kaneo 可能不适合你，还是老老实实用 Jira。但如果你的团队在 10 人以内、想快速把项目管理跑起来、又不想让数据躺在别人服务器上，Kaneo 值得一试。

---

一些资源链接

• GitHub: github.com/usekaneo/kaneo
• 文档: kaneo.app/docs/core
• 官网: kaneo.app
• 云服务: cloud.kaneo.app
• Discord: discord.gg/rU4tSyhXXU
• Docker 镜像: ghcr.io/usekaneo/kaneo:latest

---

最后说一句

Kaneo 的答案不是"功能更少"，而是"功能恰好够用"。

这两件事听起来差不多，但做起来完全不同。前者是偷懒，后者是克制。

我用了两周，暂时没找到让我想换回 Jira 的理由。

---