我去年年底做了一件在公司内部被很多人觉得“没必要”的事把用了快五年的 Jira 直接下线换成了一个开源项目管理平台自托管部署。到现在跑了大半年产品、研发、运营三个团队一共 30 多人任务管理和项目进度一点没落下每年在 SaaS 订阅上省下来的钱足够给团队换两台新开发机。这个项目不是别的就是这两年经常被人称为“Jira 杀手”的开源管理工具 Plane。很多人一听到“自托管”就头疼其实用 Docker 部署远比想象中简单今天就把我踩过的坑和完整的原生 Docker 部署过程一次性说清楚。1. 我为什么决定把 Jira 换掉1.1 先算一笔“隐形账单”以前团队小的时候我其实没怎么关注过 Jira 的订阅费用都是按人头直接续费。真正让我动摇的是去年续费时的账单标准版的按用户订阅看着不贵但团队一旦超过 20 人再加上部分高级版权限位、Confluence 的联动费用、偶尔额外买的附件存储扩容一年下来轻松破万。这里不是吐槽具体价格而是说这套按“活跃用户”收费的模式在小团队里非常不划算——很多同事一个月就登几次甚至只是被拉进去看板而已却一样要占订阅位。如果换成开源方案自托管服务器成本其实低得吓人。我用了一台 4 核 8G 的云主机按现在的市场价格一年主机费用大约几千元。也就是说同样承担 30 人团队的项目管理工作SaaS 订阅费从大几万直接降到几千省下来的至少有三四万。这个账不需要财务精算师打开 Excel 就能算明白。1.2 开源软件让我拿回了“掌控权”除了省钱我更在意的是数据和控制权。SaaS 平台虽然好用但数据始终在别人手里牵涉到项目进度、商务客户名称、内部排期这类信息总让人不太安心。自托管之后数据库、对象存储、前端静态文件全都在自己的服务器里整个系统的备份策略、审计权限、白名单访问都是自己说了算这种感觉和租用别人的服务是完全不同的。当然开源也不是“免费午餐”它需要你有一定的维护意识。好消息是Plane 这种主流的开源项目管理工具已经把复杂度压得很低特别是有 Docker 和 Docker Compose 之后部署过程被极大简化。只要愿意花一个下午一个小团队也能把一套项目管理平台完整跑起来。2. 部署前的准备服务器、系统与工具链2.1 服务器规格和系统选择先说硬件。Plane 其实是一整套微服务架构包含前端、后端、后台任务队列、数据库、对象存储、反向代理等。开发环境 2 核 4G 也能勉强跑但如果真想稳定使用建议 4 核 8G 起步磁盘至少 40G SSD。如果团队附件特别多比如截图、文件、视频素材都往里传建议直接把数据盘单独挂到 100G 以上避免以后扩容时手忙脚乱。系统方面我推荐 Ubuntu 22.04 LTS这也是大多数云厂商默认提供的镜像。为什么不用 CentOS不是不能用而是 Ubuntu 的包管理器、Docker 安装源都太省事了社区文档里踩坑案例也最少。我自己是在一台 Ubuntu 22.04 上部署的整个过程中唯一遇到比较折腾的问题跟操作系统本身没关系而是我第一次没把数据目录规划好后来迁移备份时多花了一个小时。2.2 安装 Docker 和 Docker Compose如果是全新的服务器第一步是把 Docker 安装好。以 Ubuntu 为例通常我习惯用官方仓库而不是系统自带的旧版本因为旧版可能不带 Docker Compose 插件。sudo apt update sudo apt upgrade -y sudo apt install -y ca-certificates curl gnupg lsb-release curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin安装完检查一下版本docker --version docker compose version我记得我装的时候 Docker 版本是 24.xDocker Compose 插件是 v2.20 以上。只要docker compose version能输出信息后面就没问题。建议把当前用户加进 docker 组免得每次都要敲 sudosudo usermod -aG docker $USER newgrp docker这里有一个小提醒如果你用的是云厂商的“轻量应用服务器”部分默认系统镜像里已经带了 Docker但可能是老版本。先检查再继续避免后续 compose 文件的语法不兼容。3. 原生 Docker 部署实操3.1 获取官方部署包Plane 的代码托管在 GitHub仓库名字是 makeplane/plane。官方仓库里不仅有完整源码还专门维护了一套供自托管用户使用的 Docker 部署配置放在 deploy 目录下。所谓“原生 Docker 部署”我理解就是不装额外面板、不用一键脚本直接通过 Docker Compose 把整个服务栈拉起来。先建一个干净的部署目录然后克隆仓库mkdir -p /opt/plane cd /opt/plane git clone https://github.com/makeplane/plane.git .注意这种方法会把整个源码仓库也拉下来其中包含前端和后端的完整代码很多文件我们并不需要。只想快速部署的话其实只要保留 deploy 目录和里面的配置就够。如果你不想在服务器上保留源码也可以单独把 deploy 目录下载下来但直接 clone 对我来说最省心后面升级的时候git pull也方便。进入 deploy 目录里面通常会有一个.env.example文件这是所有环境变量的模板cd /opt/plane/deploy ls -la我看到这个目录下会有 compose 文件比如docker-compose.yml之类不同版本命名可能稍有差异。如何确认自己该用哪个文件优先看仓库 README。如果只是想快速跑起来直接以.env.example为模板创建.env文件。3.2 配置 .env域名、端口与密钥部署中最容易出错的地方就是环境变量。首次接触的人看到一堆变量会发懵其实核心就几项cp .env.example .env vim .env需要重点关注这几个变量NGINX_PORT对外访问的端口默认 80。如果服务器 80 已被占用可以改成一个自定义端口比如 8080。WEB_DOMAIN这是访问 Plane 的域名比如plane.example.com。如果暂时没有域名可以先填服务器公网 IP但后续要改的话需要同步调整一些登录态参数。POSTGRES_DB、POSTGRES_USER、POSTGRES_PASSWORD数据库名称、账号、密码。建议改成强密码类不要用默认值。SECRET_KEY这是整个应用的关键密钥用于加密 cookie、签名 token。务必生成一串随机值不能留空。MINIO_ROOT_USER和MINIO_ROOT_PASSWORD对象存储的账号和密码附件文件就存在这里。生成一个随机密钥的办法有很多我用的是最简单的方式openssl rand -hex 32把输出结果复制到.env里的SECRET_KEY位置。为什么说这个变量不能随便改因为应用启动后所有登录态的 cookie 和用户 token 都是基于它签名的。如果你第一次启动后突然修改已经登录的用户会被强制下线甚至会出现奇怪的鉴权错误。3.3 启动整个服务栈配置好.env之后开始拉镜像、启动服务。这里我首先会看一下 compose 文件里定义的服务列表确认都包含什么docker compose -f docker-compose.yml config --services确认无误后直接启动docker compose up -d第一次启动会从 Docker Hub 拉取镜像此时需要等一会儿。Plane 的镜像体积不算小web 前端、api 后端、worker 任务队列、数据库、Redis、MinIO 这些加在一起冷启动下载可能需要十几分钟具体取决于服务器带宽。等待期间可以看一下镜像拉取过程如果某个镜像反复拉取失败大概率是网络问题。启动完成后检查容器状态docker compose ps只要所有容器状态都是 Up基本可以访问了。这时在浏览器输入服务器 IP 或你配置的域名应该能看到初始化页面。如果页面打不开最优先排查的是防火墙安全组尤其是云服务商的安全组规则——记得放行 NGINX_PORT 对应的端口。3.4 容器分工和职责说明我在这套部署里看到的最直观感受是“组件多”。很多刚接触 Docker 的人容易被吓到但我拆开说明一下会发现每个服务都有清晰职责proxyNginx 反向代理充当流量入口把请求转发给前端或后端。webNext.js 渲染的前端服务负责界面。apiDjango 写的后端接口服务处理业务逻辑。worker后台异步任务消费者比如邮件发送、导入导出、定时任务都靠它。beat-worker定时任务调度器负责周期性任务。postgres主数据库存业务数据。redis缓存和消息队列辅助异步任务。minio对象存储存放附件、图片等静态文件。migrator数据库迁移任务只在首次启动时跑一次负责初始化表结构。可以想象成一家餐厅你进门看到的是前端服务员也就是 web点单后传给后厨 api后厨忙不过来时把耗时间的菜品交给 worker食材要放仓库那就是 postgres 和 minio。这套逻辑捋顺之后排查问题就会从容很多。4. 初始化和从 Jira 迁移数据4.1 创建管理员账号与工作区浏览器打开页面后第一步是创建管理员账号。这个账号就是系统里的“超级管理员”权限相当于 Jira 的 Site Admin。创建完成之后系统会让你创建工作区。工作区这个概念可以理解为公司的整体空间里面可以包含多个项目。创建项目时它会问项目名称、标识符等。这里的项目对应 Jira 里的 Project标识符则像一个短代码比如 DEV、OPS用来快速区分不同项目。初始化流程完成后我建议先把成员邀请进来再开始配置项目卡片和状态流。顺序不同也能用但先建立成员列表会让后续配置更顺手。4.2 从 Jira 导出历史数据并导入团队最担心的问题就是“历史数据怎么搬”。Plane 支持通过 CSV 或 JSON 批量导入而 Jira 官方也支持将问题列表导出为 CSV。实际操作时我先把 Jira 里需要迁移的旧项目导出成 CSV 文件然后在 Plane 的项目设置里找到导入入口上传这个 CSV。系统会要求映射字段比如 Jira 里的“摘要”对应 Plane 里的“标题”“经办人”对应“负责人”“优先级”对应“优先级”。这个映射过程很像给 Excel 表格做列匹配第一次操作大约 10 分钟能完成。需要提醒的是编码问题。如果 CSV 里全是中文上传后出现乱码多半是文件编码不是 UTF-8。用文本编辑器把 CSV 另存为 UTF-8 编码再上传问题基本就能解决。如果遇到日期字段导入后对不上建议在导出前就把 Jira 的日期格式调整成通用的 yyyy-MM-dd。4.3 权限模型和项目配置Plane 的权限模型比较简洁有 Owner、Admin、Member、Guest 几个层级。Owner 一般只保留给团队负责人Admin 可以配置工作区级的东西Member 负责日常任务管理Guest 适合外部协作者。权限粒度虽然没有 Jira 那么夸张但对大多数中小团队已经够用。我实际配置时把产品经理和研发组长设为 Admin其他研发和测试设为 Member外部临时外包人员用 Guest 权限。这样既保证日常协作效率又不会让人误删工作区配置。5. 使用体验、常见问题与排查记录5.1 部署后我踩过的几个坑这半年里我最常被同事问的问题是“你们自托管是不是老要修”其实真实情况是只要前期部署规范后续维护频率非常低。我主要踩过的坑就三个。第一个坑是域名配置没填导致登录链接带端口。第一次部署时我图省事只用 IP 访问结果用户注册后收到激活邮件里的链接带着内网 IP 地址远程根本点不开。后来我把WEB_DOMAIN配置成真实域名并重新启动问题才解决。如果你有域名一定要在部署初期就填上不要后期改。第二个坑是 SMTP 邮件没配好。统一登录和找回密码全靠邮件通知我一开始跳过了邮箱配置测试发邀请时一直提示失败。后来在系统设置里填了公司的 SMTP 服务器和账号发件测试通过才能正常邀请成员。这个是自托管最容易忽略的点很多文档会把邮件配置放在最后但它其实是多人协作上线前必须解决的。第三个坑是 MinIO 对象存储的密码变更后旧附件无法访问。有一次我在调整服务器环境变量时顺手改了 MinIO 的 Root 密码导致已上传的附件路径签名失效页面图片全部裂开。核心教训是涉及存储的密钥一旦初始化就不要随意修改真要改密钥得连存储桶里的数据一起重新生成访问策略。5.2 常见问题速查表这里整理一份我在使用过程中遇到或听其他自托管用户提过的常见问题方便直接对照排查现象可能原因处理方法打开 IP 地址无法访问页面安全组未放行端口检查云平台安全组和服务器防火墙放行 NGINX_PORT 对应端口容器反复重启api 日志报数据库连接失败postgres 容器还在初始化或内存不足查看 postgres 容器状态等待初始化完成必要时给 docker 服务分配更多内存上传附件后一直加载MinIO 配置异常或对象存储服务未启动检查 minio 容器日志核对 .env 中的存储账号密码邮件通知发不出去SMTP 配置错误在系统设置内重新配置 SMTP 服务器并先运行测试发信忘记管理员密码密码找回依赖 SMTP如果邮箱不可用可以在数据库里临时修改用户状态或重建初始化脚本升级后界面显示异常前端静态资源缓存清除浏览器缓存或强制刷新后重新登录系统运行一段时间后磁盘空间不足附件、数据库日志过多定期清理旧附件配置日志轮转并扩容数据盘5.3 备份、升级与长期维护建议自托管系统最怕数据丢失所以备份一定要重视。我目前的做法是每天凌晨用 crontab 分别备份 PostgreSQL 数据库和 MinIO 的数据目录。数据库备份命令类似docker compose exec postgres pg_dump -U plane plane /backup/plane_$(date %Y%m%d).sqlMinIO 那边我直接把挂载出来的数据目录整体备份。如果用的是云主机还可以把备份文件同步到对象存储里这样即使整台服务器宕机也能在另一台机器上恢复。升级方面Plane 社区版迭代力度很大官方每次发版都会在 README 里强调升级步骤。通用的做法是先备份数据然后进入 deploy 目录执行git pull之后重新构建镜像并启动。切忌生产环境直接latest标签升级最好先在小服务器上测试完再操作。我个人的习惯是部署时固定一个版本号比如v0.24.x确认稳定后再统一升级。5.4 和其他开源项目管理方案的横向比较做完这次迁移后也有人问我为什么不选 OpenProject 或 Focalboard我确实对比过。Plane 的界面风格更现代更贴近现在年轻团队的使用习惯学习成本低OpenProject 功能很强尤其适合传统项目管理和甘特图场景但界面老气一些配置也更重Focalboard 作为看板工具非常轻量但功能边界有限不太适合需要复杂工作流的中型团队。如果你主要是看板加迭代管理Plane 的 Cycles 模块特别顺手如果你要完整的企业级项目组合管理OpenProject 反而更适合。工具开源Docker 部署难度典型适用场景Plane是中等中小团队看板、迭代、项目文档OpenProject是较高需要传统甘特图、进度管理的团队Focalboard是容易个人或小团队轻量看板Taiga是中等敏捷开发团队经典 Scrum/KanbanJira否不适用追求全家桶和企业集成的团队说这么多我最想表达的是工具本身不分高下关键是预算、团队规模和流程适配度。如果你和我一样对成本敏感又想保留数据主权那 Plane 这套自托管方案非常值得尝试。最后再分享一个经验迁移的时候别急着把旧系统一刀切关掉。我建议在正式切换后的第一个月保留 Jira 的只读访问权限让团队成员有个适应期。等新系统跑顺了、历史数据也核对无误再彻底停掉旧订阅这样既不耽误业务也不用为退路焦虑。