Jira Data Center 漲 15% 還順手停售新授權：Plane 用一支 Docker compose 把專案管理搬回自家機房

2026 年 2 月 17 日，Atlassian 把 Data Center 的標準價碼一次往上拉 15%；3 月 30 日，整條產品線停止對外販售新授權。Server 版兩年前就先消失，現有客戶必須在 2028 年 3 月底前把該續的續完，否則 2029 年 3 月 28 日 EOL 之後整套變成唯讀。剩下的選項只有 Cloud——而 Jira Cloud Enterprise 的報價是每人每月 17.5 美元。

對於不想把工作流跟整個 issue 歷史搬上別人雲端，或單純算過帳之後決定不付這筆錢的團隊，自架的選擇實際上正在收斂到少數幾個還算可用的方案。Plane 是當中市場聲量最大的一個：Community Edition 走 AGPL-3.0、整套用 Docker Compose 起得來、UI 是現代化的 React，不是 GitLab CE 那種 10 年沒整理過的後台。

Plane 跟 Linear、Jira 走的路線到底差在哪

Plane 自稱是 Jira、Linear、Monday、ClickUp 的開源替代品，但真正影響架構與適用情境的是它對「Work Item」的抽象方式。Jira 的核心是高度可客製的 Issue Type 與 Workflow，付出的代價是配置介面複雜到 admin 要另外進修；Linear 則反過來，犧牲彈性換取一致的 UX 跟反應速度。Plane 走中間路線：核心物件是 Work Item，外面套上 Project、Cycle（衝刺）、Module（功能模組）、Page（文件）四層組合。

對於小團隊到中型軟體部門這是務實的選擇。需要 Jira 那種跨部門 schema 的場景，Plane 確實做不到，但多數 50 人以下的工程組織原本也用不到那層。值得注意的是，Plane 從 1.0 之後把 AI workflow 內建進 Community Edition，可以自己接 OpenAI 相容的 endpoint，不必走 SaaS。

看一下這套 Docker stack 在跑些什麼

Plane 自架不是一支 binary 那麼簡單。一個完整的 Community Edition 部署會起六支主要 service：

Plane Web（Next.js 前端）
Plane API（Django + DRF 後端）
Plane Worker（Celery，跑背景任務）
Plane Beat（Celery scheduler）
Plane Space（公開頁面服務）
Plane Admin（God Mode 管理介面）

外加四支 infrastructure：PostgreSQL 作為主資料庫、Valkey 取代 Redis 處理 cache 與 session、RabbitMQ 給 Celery 用作 broker、MinIO 作為 S3 相容的物件儲存層，用來存附件跟匯出檔。

這個組合在 2 GB RAM 的小型 VPS 上勉強跑得起來，但實際拿來服務 20 人以上的團隊就會開始喘。Plane 官方建議的入門規格是 4 vCPU 配 8 GB RAM，這跟同樣等級的自架 GitLab CE 比已經算清淡。

實際的 docker-compose.yml 大致是這個樣子：

services:
  web:
    image: makeplane/plane-frontend:v1.3.0
    depends_on: [api]
    restart: unless-stopped
  api:
    image: makeplane/plane-backend:v1.3.0
    env_file: plane.env
    depends_on: [plane-db, plane-redis, plane-mq]
    restart: unless-stopped
  worker:
    image: makeplane/plane-backend:v1.3.0
    command: ./bin/worker
    env_file: plane.env
    depends_on: [plane-db, plane-redis, plane-mq]
  plane-db:
    image: postgres:15-alpine
    volumes: ["pgdata:/var/lib/postgresql/data"]
    environment:
      POSTGRES_PASSWORD: ${PGPASSWORD}
  plane-redis:
    image: valkey/valkey:7.2-alpine
  plane-mq:
    image: rabbitmq:3-management-alpine
  plane-minio:
    image: minio/minio
    command: server /data --console-address ":9090"
    volumes: ["uploads:/data"]

volumes:
  pgdata:
  uploads:

正式環境別把 PostgreSQL 跟 MinIO 跟前後端綁在同一個 Docker host。資料庫拉一臺 managed Postgres 或獨立 VM，MinIO 換成外部 object storage，這是團隊規模超過 10 人之後一定會踩到的瓶頸。Plane 1.3 之後額外提供分散式部署的 compose profile，把資料層拆出去比想像中容易。

從 Jira 搬資料過去這件事的真實成本

Plane 提供 Jira 匯入功能，但別期待是無痛的 lift-and-shift。實際路徑是先用 Atlassian 的 REST API 抓出 issue export，再透過 Plane 的 importer 對應到 Work Item。Custom Field、Workflow Status、Sprint History 通常會有 5% 到 15% 的資料對不齊，特別是用了大量 add-on 的 Jira instance——那些自定義欄位在 Plane 沒有等價物，要嘛轉成 free-form description，要嘛在 importer 設定階段手動 mapping。

Workflow 的搬移最折磨。Jira 一個專案常常有 10 種以上的 transition rule，Plane 採用比較簡化的 state machine 設計（Backlog / Todo / In Progress / Done / Cancelled 為基底，可自訂額外狀態）。如果原本的 Jira 流程依賴複雜的 condition、validator、post-function，這些邏輯沒辦法平移，得在 Plane 用 Automation 或 webhook 重做。

一個務實的建議：搬移時不要試圖在新系統重建舊系統的所有規則。Jira 的複雜度有一半是組織遺留下來的歷史包袱，搬到 Plane 的契機正好是清掉這些。把當前還在跑的 active project 搬過去，封存的歷史專案以 read-only 形式留在 Jira 直到 EOL，這樣的拆分能把搬移工作壓縮到原本估算的三分之一。

Plane 不如 Jira 的地方在哪

幾個情境 Plane 目前確實還搆不上 Jira。

跨專案的關聯查詢：Jira 的 JQL 語法雖然醜，但跨 200 個專案做複雜條件搜尋是即時的。Plane 的查詢能力綁在單一 workspace 內，跨 workspace 的 aggregation 需要靠 REST API 自己組。

進階權限：Jira 的 Permission Scheme 可以細到單一欄位等級的 read/write 控制，Plane 的權限模型只到 Project Member、Admin、Guest 三層。對於有合規需求、需要稽核日誌的金融或醫療業，這層做不到位。

Marketplace add-on 生態：Jira 那套兩千多個 plugin 的生態系不是短時間能複製。Plane 的 webhook 跟 API 雖然完整，但需要工程資源自己寫整合。

這三點不會改變的事實是：付得起 Atlassian Cloud Enterprise 的大型企業，Plane 不是這次該評估的對象；中小型工程團隊跟內部工具團隊才是它的真實 TAM。

上線之前該想清楚的維運責任

自架專案管理系統的最大隱形成本不是 VPS 費用，而是備份策略跟升級節奏。Plane 的資料分散在 PostgreSQL（核心資料）、MinIO（附件）、Valkey（session，可丟）三個地方，做 disaster recovery 必須三個一起做。光備份 PostgreSQL 卻忘了 MinIO 的後果是 issue 還在、附件全沒，這在實際 incident 上比想像中常見。

備份的標準做法是 PostgreSQL 用 pg_dump 或 pgBackRest 走 WAL streaming，MinIO 用 mc mirror 同步到外部 S3 或冷儲存，每天執行並監控 backup 完成事件。Restic 也可以用來統一處理整個 stack 的快照，方便加密與異地保存。

升級節奏方面，Plane 維持每兩到三週的 minor release，重大 schema migration 通常一年一兩次。生產環境的版本固定原則跟其他自架服務一樣：不要追 latest tag、釘住具體版本號碼、新版發布後在 staging 跑兩週再 promote。AGPL-3.0 的授權雖然要求對外提供服務時公開改動的程式碼，但純粹自架不改動原始碼的場景並不會觸發這個義務，多數團隊不必過度擔心法律風險。

何時值得做這個搬遷

Atlassian 的政策方向已經明確：Server 沒了、Data Center 兩年內也只能續租到底，剩下的唯一出口就是 Cloud。對「不上 Cloud」這條路有強烈偏好的團隊，Plane 是少數已經夠成熟的選擇。對「上 Cloud 但對每人每月 17.5 美元嫌貴」的團隊，Plane 自架在 50 人規模下能省下五位數美金的年費，搬移工程量在兩到四週內可以收斂。

但 Plane 不是給所有 Jira 用戶的萬靈丹。如果現行的 Jira 已經跑得穩、流程也熟，Cloud 漲價對組織財報是小數點後的議題，那繼續用 Jira Cloud 是合理選擇。會掙扎是否要搬的真正族群，是那些用 Server 或 Data Center 自架慣了、不想學新的 admin UI 也不想付 Cloud 費用的中型工程組織——這群人剛好就是 Plane 的目標市場。

把這套 Docker stack 跑在臺灣機房，可以避開 Atlassian Cloud 跨海連線延遲的問題，也讓專案資料留在本地監管範圍內。NCSE Network 的 VPS 採用臺灣是方電訊機房、Intel Gold CPU 與 NVMe SSD，從 4 vCPU/8 GB 的入門配置到適合 50 人團隊的中型機型都有對應規格，如有自架 Plane 或其他 DevOps 工具的部署需求，可以到 ncse.tw 看細節。