Kanboard 1.2.56 介绍与选型指南

Kanboard 1.2.56 开源看板项目管理软件的介绍与选型指南：定位架构、功能特性、快速上手，附与 Wekan/Vikunja/Plane/Restyaboard 的量化选型对比（数据溯源官方渠道，查询日期 2026-10-23）。

KanboardKanboard项目管理看板自托管PHP 应用2026/10/24

Kanboard 1.2.56 介绍与选型指南

目标：说清 Kanboard 这一开源看板项目管理软件的定位、架构、功能边界与同类竞品差异，帮助读者在 Wekan、Vikunja、Plane、Restyaboard 等同类工具中做出有依据的选型决策。本文为认知与选型篇，全部信息均溯源自官方渠道（官网 kanboard.org、GitHub Releases、官方文档站 docs.kanboard.org）与 shields.io 实时徽章数据，未含本地性能实测结论。

一、环境信息

本文是纯联网溯源的认知篇，不涉及本地部署实测；为保证可复核性，先交代信息来源与查询口径。

二、软件概述

本节回答「Kanboard 是什么、为谁而生、解决什么问题」三个基本问题，为后续架构与选型章节建立语境。

Kanboard 是一款免费开源的看板（Kanban）项目管理软件，由法国开发者 Frédéric Guillot（同为 RSS 阅读器 Miniflux 的作者）主导开发，采用宽松的 MIT 许可协议发布，至今已有超过 334 位贡献者参与（官网 kanboard.org 首页，查询日期 2026-10-23）。它的核心方法论来自精益生产的看板思想：可视化你的工作、限制在制品（WIP）数量以聚焦目标、通过拖拽任务在列间流转来推进项目。

与同类产品相比，Kanboard 最鲜明的特征是「克制」：官网明言 "There is no fancy user interface, Kanboard focuses on simplicity and minimalism. The number of features is voluntarily limited."（没有花哨的界面，专注简洁与极简主义，功能数量是自愿限制的）。它不追求成为 Trello/Jira 的全功能复刻，而是做一个单人或小团队即可低负担自托管、资源占用极低、数据完全自主的看板工具。

关键身份信息汇总（来源：官网与仓库，查询日期 2026-10-23）：

维度事实
软件定位自托管开源看板项目管理
首要维护方Frédéric Guillot（个人主导 + 社区贡献，334+ 贡献者）
开发语言PHP（v1.2.56 运行时为 PHP 8.5，见其 Release Note）
数据库默认 SQLite，可选 MySQL / MariaDB / PostgreSQL
许可MIT
当前稳定版v1.2.56（2026-10-21）
部署形态官方提供 Docker 形态与源码归档部署（tar.gz），本站另交付 Docker Compose 部署篇
配套能力自带 CLI 工具（./cli）、JSON-RPC API（jsonrpc.php）、插件体系

💡 技术拓展：看板（Kanban）与 Scrum 是敏捷落地的两大主流流派，自托管看板工具也常按此分野——

方法论核心机制典型自托管实现
看板 Kanban可视化流动 + WIP 限制 + 持续交付，无固定迭代Kanboard、Wekan、Restyaboard
Scrum固定 Sprint、角色分工、燃尽图等仪式Plane、Taiga
混合形态看板视图 + 议题跟踪/迭代可选Vikunja、OpenProject

Kanboard 属于「纯看板」流派的最简实现；若团队需要 Sprint 规划、燃尽图等 Scrum 仪式，应倾向 Plane/Taiga 一类（见第七节量化对比）。

三、核心架构

本节从官方资料出发梳理 Kanboard 的技术架构与运行形态，帮助读者理解它「为什么轻」。

Kanboard 是一个典型的单体 PHP Web 应用，无独立常驻后台进程：由 Web 服务器（官方部署形态内置 Apache + PHP）直接解析 PHP 代码，数据库通过 PDO 抽象层访问，浏览器直接与该 Web 服务交互。任务流转、邮件通知等异步动作由内置的定时任务（cronjob 形式调用其 CLI 入口）驱动，而非独立的消息队列。这种架构决定了它的两个突出特点：部署面极窄（一台支持 PHP 的主机 + 一个数据目录即可运行）与水平扩展能力有限（单体应用 + 文件附件存储，适合中小团队而非大规模并发场景）。

3.1 数据模型与存储

Kanboard 的核心数据对象围绕「项目 → 看板列 → 任务」三级展开，向下细分出子任务（Subtask）、评论、附件、外链、自定义字段等；任务之间支持依赖关系，项目支持私有/公开与多成员角色。存储层通过 PDO 支持三种数据库，默认为零配置的 SQLite（数据落在一个 data/ 目录下的单文件中，备份等价于复制文件），生产规模较大时可切换 MySQL/MariaDB 或 PostgreSQL（切换方式见本站《Kanboard 1.2.56 配置参数详解》篇的 DB_* 参数说明）。

💡 技术拓展：三种数据库后端的取舍——

后端部署成本并发写入备份方式适用场景
SQLite（默认）零外部依赖，单文件低（写锁串行）复制单文件单机/小团队/低写入频率
MySQL / MariaDB需额外数据库服务中高mysqldump/物理备份中等团队、需远端 DBA 管理
PostgreSQL需额外数据库服务中高pg_dump已有 PG 运维体系的团队

Kanboard 默认采用 SQLite，理由是看板类应用的写入频率天然较低（人工拖拽与编辑为主），SQLite 足以支撑小团队场景且免除了独立数据库的运维负担；团队超过数十人或有大量 API 自动化写入时再迁移 MySQL/PostgreSQL。

3.2 对外接口：Web UI、CLI 与 JSON-RPC API

Kanboard 对外提供三个通道：

  1. Web UI：主要的日常交互入口，看板/列表/日历（iCal 订阅）/甘特图等多视图；
  2. CLI 工具：源码根目录的 ./cli（基于 Symfony Console），覆盖项目管理、用户管理、任务创建、数据库迁移等运维动作，官方镜像与源码部署均可用，本站《Kanboard 1.2.56 常用 CLI 命令详解》篇逐条实测；
  3. JSON-RPC API：入口为 jsonrpc.php，官方文档（docs.kanboard.org/api/）声明支持通过 HTTP 携带 X-RPC-Auth-Username/X-RPC-Auth-Password 或 API 访问令牌调用全部业务方法，是外部系统（如工单系统、CI 流水线）自动建卡的标准通道。

3.3 认证体系与插件机制

认证方面，Kanboard 内置本地账号体系（含用户名/密码、双因素验证码），并支持外接 LDAP/Active Directory 后端与任意 OAuth2 提供方（官方文档列举 Google、GitHub、GitLab 等），可按用户级别配置「本地 + 远端」混合登录。安全治理上支持登录失败锁定、验证码、反向代理头信任等配置项（v1.2.55 的安全修复也集中于此区域，见 4.2）。

插件方面，Kanboard 通过源码 plugins/ 目录加载扩展，社区插件市场见 kanboard.org/plugins（含自定义主题、甘特图增强、Messenger/Slack 通知桥接等）。插件即 PHP 代码目录，安装方式为下载后放入目录，卸载即删除，不影响核心数据。

四、功能特性

本节归纳官网声明的功能清单，并补充版本动态，读者可据此评估功能面是否覆盖自身需求。

4.1 官网声明的核心功能（来源 kanboard.org，查询日期 2026-10-23）

  • 可视化看板：任意增删改名看板列，拖拽任务在列间流转，所见即所得；
  • WIP 限制：为列设定在制品上限，超限时列高亮告警，强制聚焦；
  • 任务体系：任务/子任务拆分、工时与复杂度估算、Markdown 描述、评论、附件、颜色、分类、负责人、到期日、任务间移动与一键复制；
  • 搜索与过滤：内置一套简洁查询语言，按负责人、描述、分类、到期日等动态过滤看板（语法速查见官方文档 docs.kanboard.org 的 Search 段）；
  • 自动动作（Automatic Actions）：基于事件的工作流自动化，如「任务移入某列时自动指派给某人」「到期日变更时自动改色」等，官方宣称可覆盖绝大多数重复操作；
  • 多视图：看板、列表、日历（iCal 订阅导出）、甘特图等；
  • 多语言：官方列出 30+ 语言，含简繁中文；
  • 多认证后端：本地账号 + LDAP/AD + OAuth2（Google/GitHub/GitLab 等）；
  • 分析面板：项目分析（累积流图、周期/前置时间统计）帮助度量流动效率。

4.2 版本动态与安全响应（来源 GitHub Releases，查询日期 2026-10-23）

近两个版本均为安全修复型发布，可见上游对安全问题的响应节奏：

  • v1.2.56（2026-10-21）：将官方 Docker 运行时配置从 PHP 8.4 升级到 PHP 8.5（当前 Alpine 包解析为 PHP 8.5.12），修复 CVE-2026-109618 与 CVE-2026-109619；
  • v1.2.55（2026-10-21）：三项安全修复——防止伪造客户端 IP 绕过基于 IP 的验证码与登录锁定；限制仪表盘与逾期任务查询仅命中用户有权访问的项目；在关闭看板列时强制项目级权限校验。

⚠️ 注意：若现网运行 v1.2.54 及更早版本，应尽快升级至 v1.2.56——v1.2.55/1.2.56 的修复点（IP 伪造绕过锁定、越权查询）均属可远程利用面。

五、快速开始（最小可用示例）

本节按官方文档的部署后首登流程走一遍最小可用闭环（本篇为纯溯源篇，步骤依据官方文档描述整理并标注来源，未做本地实测；带真实命令回显的部署与验证请使用本站部署篇与命令篇）。

  1. 部署：采用官方推荐的 Docker 形态（或源码归档 tar.gz 解压至 Web 根目录），部署全流程与持久化配置详见本站《Kanboard 1.2.56 Docker Compose 部署指南》篇；
  2. 首次登录：浏览器访问服务地址，默认账号 admin、默认密码 admin（官方文档 docs.kanboard.org 声明），登录后系统会提示修改密码——首次登录取「修改资料 → 修改密码」将默认口令改为强口令（本文示例环境统一使用测试口令 q1w2e3r4，生产环境务必另行设置）；
  3. 创建项目：左侧「项目管理 → 新项目」，输入项目名（如「运维任务看板」）创建；
  4. 组织看板列：进入项目看板视图，按团队流程添加列，例如「待办 → 进行中 → 测试 → 已完成」，并可为「进行中」列设置 WIP 限制（如 3）；
  5. 创建并流转任务：在列上点击「+」创建任务（填写标题、负责人、到期日），拖拽卡片跨列流转，观察列上 WIP 计数变化；
  6. 验证自动化：项目设置 →「自动动作」中添加一条「任务被移动到『已完成』列时自动指派给我」，随后拖拽一张卡片到该列，验证动作是否生效。

完成以上六步即得到一个可日常使用的最小看板；后续可按需接入 LDAP/OAuth2 登录、配置 SMTP 通知、通过 JSON-RPC API 对接外部系统。

六、适用场景与限制

本节给出 Kanboard 的适用边界，避免「一把梭」式选型。

6.1 适用场景

  • 小中型团队的任务流转：数人到数十人规模的团队，流程以看板拉动为主，不需要重度 Scrum 仪式；
  • 低资源自托管：单台小型主机（如 1~2GB 内存的 VPS）即可承载，默认 SQLite 免去独立数据库运维，适合家庭实验室、个人效率管理、初创团队；
  • 数据自主与极简运维：MIT 许可 + 纯 PHP 单体 + 单文件数据库备份，几乎不存在「平台锁定」；
  • 需要 API 自动化建卡：工单系统、CI 流水线、表单系统通过 JSON-RPC API 自动推送任务到看板。

6.2 限制与不适用场景

  • 不做企业级议题跟踪：无原生的测试用例管理、代码评审、CI 集成等（这些是 Plane/Taiga/OpenProject 的领地）；
  • 单体内存的扩展上限：极大规模组织（数百人以上、高频并发写入）应评估独立数据库后端，并对附件存储做外置规划；
  • 功能克制是双刃剑：官方「自愿限制功能数量」意味着报表、自定义工作流深度等诉求需靠插件或 API 外部化实现；
  • 无移动原生 App：移动端依赖响应式 Web（社区有第三方 App，但非官方一线支持）。

七、同类选型对比

本节以量化维度横向对比 Kanboard 与四款常见开源同类产品，全部数据来自 shields.io 实时徽章与各项目官方仓库（查询日期 2026-10-23），星数与提交数为动态数据，引用时请注明查询日期。

7.1 社区活跃度与版本节奏量化对比

项目仓库GitHub Stars最新 Release（实查）月提交数主语言栈许可
Kanboardkanboard/kanboard9.9kv1.2.56（2026-10-21）19PHP + SQLite/MySQL/PGMIT
Wekanwekan/wekan21kv12.63（实查 2026-10-23）9.1k（含自动化提交）Meteor/Node.jsMIT
Vikunjago-vikunja/vikunja5.8kv2.7.1（实查 2026-10-23）657Go + Vue.jsAGPL-3.0
Planemakeplane/plane61kv1.4.2（实查 2026-10-23）79Python(Django) + Next.jsAGPL-3.0
RestyaboardRestyaPlatform/board2.1kv1.7.1（实查 2026-10-23）0（徽章口径）PHP + PostgreSQL + ElasticSearchOSS/商业双许可

表格解读（关键差异）：

  • 热度 ≠ 活跃度：Plane 星数最高（61k，面向 Jira 替代的营销与社区运营更强），但按徽章口径其月提交数（79）低于 Vikunja（657）；Wekan 月提交数 9.1k 明显含大量自动化/机械性提交，不能直接等同于人工开发强度；
  • 版本节奏：Kanboard 在 2025-08 至 2026-10 间连发 v1.2.47→v1.2.56 共 10 个版本（releases.atom 实查），其中 2026 年 1-10 月发布 8 个，节奏稳定在 1~3 个月一版，安全响应快（见 4.2），属于「小步快跑、维护健康」的单人主导项目；
  • Restyaboard 谨慎评估：月提交徽章为 0、星数 2.1k，社区动能已明显落后，且许可为双许可（自托管用其开源版需仔细核对条款），新选型不建议首选；
  • 许可差异：Kanboard/Wekan 为宽松的 MIT，Vikunja/Plane 为 AGPL-3.0（对二改分发与 SaaS 化有传染性约束），合规敏感团队需注意。

7.2 功能与运维维度对比

维度KanboardWekanVikunjaPlaneRestyaboard
部署复杂度极低（PHP 单体，默认 SQLite）中（Meteor 栈，Node 资源占用偏高）中（Go 二进制 + 独立 DB）高（多服务：后端/前端/消息队列/对象存储）高（依赖 PostgreSQL + ElasticSearch + Redis）
默认数据库SQLiteMongoDBMySQL/PostgreSQL/SQLitePostgreSQLPostgreSQL
方法论流派纯看板 + WIP纯看板 + WIP看板 + 列表 + 甘特Scrum/看板混合（议题跟踪型）看板（Trello 风格）
APIJSON-RPC（成熟稳定）RESTRESTREST + GraphQLREST
CLI 工具自带 ./cli无官方 CLI无官方 CLI无官方 CLI无官方 CLI
插件体系有（plugins/ 目录）弱无（靠 API 集成）无（模块化产品路线）有（R-Apps）
资源占用极轻较重轻重重

表格解读（如何选型）：

  • 要「最省心的轻量看板」→ Kanboard：一台小机、一个数据目录、备份即复制文件；维护节奏健康、安全修复快；
  • 要「Trello 观感 + 多人协作看板」→ Wekan：社区最大（21k 星），但 Meteor 栈对主机资源要求更高；
  • 要「待办/任务管理全能型（个人+团队）」→ Vikunja：Go 实现性能好、API 活跃度高（月提交 657），AGPL 许可需评估；
  • 要「Jira 替代品（Scrum + 议题跟踪）」→ Plane：产品化程度高、增长最快，但部署形态最重（多服务编排），适合有专职运维的团队；
  • Restyaboard 不建议作为新起点：活跃度数据全面落后。

💡 技术拓展：AGPL-3.0 与 MIT 的差别不止「免费与否」——MIT 允许任意闭源使用与再分发；AGPL-3.0 要求通过网络提供服务时也须向用户提供修改后的源码（网络交互条款），因此把 AGPL 项目二次开发后对外提供 SaaS 会触发开源义务。合规敏感场景（企业内部合规、对外交付产品）应优先宽松许可：Kanboard（MIT）与 Wekan（MIT）在此维度占优。

八、参考链接