用 PLANKA 管理小团队任务：Docker 部署、成员权限与附件备份

项目刚开始时，聊天消息还能当任务清单；几个人同时推进以后，谁在做、卡在哪里、哪些已经交付，就越来越难从对话里找。PLANKA 提供项目、看板、列表和卡片，把这些状态放进一个共同入口，适合小团队或个人项目先把工作整理清楚。

工具不会自动替团队定义流程。开始只建一个真实项目，三四个能解释的列表，把任务写成能够确认完成的事情。标签、负责人、截止日期各自有用途，不为了让看板看着丰富而把每张卡片填满。

PLANKA Pro 官方看板界面示例

这张图来自官方 Pro 展示页。额外视图、自定义字段和部分角色属于版本与授权范围；下文的社区版部署不能据此承诺全部提供，界面也可能随版本调整。

部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。

PostgreSQL 与附件数据都要保留

当前官方 Compose 使用 PostgreSQL 16，应用数据挂载到 /app/data。数据库保存业务状态，应用目录保存相关文件，两者一起纳入恢复。不要沿用旧文章里已经不同的附件挂载方案，却没有核对当前镜像。

先建立目录和独立密码：

mkdir -p ~/services/planka/data ~/services/planka/db
cd ~/services/planka
umask 077
printf 'PLANKA_DB_PASSWORD=%s\n' "$(openssl rand -hex 24)" > .env
printf 'PLANKA_SECRET_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

保存 compose.yaml：

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: planka
      POSTGRES_DB: planka
      POSTGRES_PASSWORD: ${PLANKA_DB_PASSWORD:?set database password}
    volumes:
      - ./db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped
  planka:
    image: ghcr.io/plankanban/planka:latest
    environment:
      BASE_URL: http://localhost:18096
      DATABASE_URL: postgresql://planka:${PLANKA_DB_PASSWORD}@postgres/planka
      SECRET_KEY: ${PLANKA_SECRET_KEY:?set application secret}
    ports:
      - "127.0.0.1:8096:1337"
    volumes:
      - ./data:/app/data
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped

数据库没有发布宿主端口，不使用免密码连接。生成的数据库密码采用十六进制，避免拼进连接 URL 时出现需要另外编码的特殊字符。SECRET_KEY 用于签名访问令牌，必须保存自己的值，不能照抄公开样例密码。

docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 planka
docker compose run --rm planka npm run db:create-admin-user

按交互提示创建管理员，凭据保存在自己的密码管理工具中。命令完成后再登录，不默认容器启动就已经有合适的管理员。长期使用固定经过验收的应用版本或摘要，数据库主版本升级另行安排。

私人入口完成一张测试卡片

ssh -L 18096:127.0.0.1:8096 user@your-server

本机打开 http://localhost:18096，建立测试项目、看板和卡片。添加一段说明、一个任务项和一份无敏感内容的小附件，移动卡片，再刷新页面，核对内容仍在。

准备正式使用时，配置 HTTPS 域名并将 BASE_URL 改为同一个正式地址。代理连接宿主机 8096，按应用需要处理长连接和上传条件，测试登录、卡片移动、评论与附件下载，不仅确认首页标题。

PLANKA 看板状态、数据库与附件关系示意

业务状态和文件数据需要一致的恢复时间点。看板能显示并不意味着附件完整，附件目录有文件也不能独自恢复任务关系。

准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。

列表围绕真实工作状态命名

“待安排、处理中、等待确认、已完成”可以作为起点，之后按实际流程调整。等待客户或外部依赖的卡片，写明等待谁、缺什么和下一次检查时间；只移动到一个叫“阻塞”的列表，仍可能没人知道怎样继续。

卡片标题描述交付物，正文补充范围与验收条件。一个任务涉及几个不同负责人或不同交付时间时，拆成能独立推进的卡片，再说明关系。反过来，也别把几分钟内连续完成的小操作拆成十几张卡片，只为统计数量。

截止日期是约定，不是填表装饰。更新计划时留下原因和新的时间，已经完成的工作也需要接收者确认。项目结束后保留真正有用的说明和附件，过期临时资料按自己的保留规则整理。

管理员与项目成员分别验收

管理员负责实例维护，日常协作建立普通账号。邀请一个测试成员，核对它能看到的项目、看板和实际操作范围；另一个未加入的账号应当按预期被限制。网页按钮是否显示，与后端是否允许操作都要实际确认。

成员离开时，处理账号、项目成员关系及既有访问凭据。仅移出一个项目，不一定同时撤销所有入口；依照当前版本的账号和会话管理能力操作，再用旧成员状态验证。

应用中的附件也可能包含业务信息。用未授权窗口测试附件访问方式，上传前清理不必要的私人字段。不要把所有合作资料放进管理员账号，只因为这样分享起来更快。

需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。

通知先证明能送达

邮件与其他通知渠道按当前版本支持方式配置。先发测试，再用测试卡片完成一次真实触发，检查收件人、链接域名和事件内容。能连到 SMTP 服务器不等于通知已经进入接收者实际查看的位置。

通知太密时，先整理哪些变化需要提醒。每次移动卡片都让所有人收到消息，会让真正需要处理的事项埋进列表。保留任务本身的清楚说明，比只依赖提醒更稳妥。

如果需要额外授权功能，先确认当前许可证和功能范围，再迁移正式工作。不要因为官方营销图出现某种视图，就让团队以为这份基础 Compose 一定提供它。

备份用数据库导出配合静止附件

暂停应用，保持 PostgreSQL 运行并导出，再保存应用目录及配置：

mkdir -p backups
docker compose stop planka
docker compose exec -T postgres pg_dump -U planka -d planka -Fc > backups/planka.dump
tar -czf "backups/planka-files-$(date +%F-%H%M%S).tar.gz" data .env compose.yaml
docker compose start planka

限制备份访问，将对应的数据库导出和文件副本一起转移到外部存储。恢复使用独立数据库、目录和原应用版本，先停用正式通知，检查账号、卡片、评论、附件与成员权限。数据库迁移后的回退，使用升级前配套材料，不把旧镜像当作完整回退方案。