Stirling PDF 3.0 在 2026 年 9 月下旬釋出時的第一條標題是「OAuth SSO 對所有人免費」。放在這半年的自架圈脈絡看，這句話幾乎是逆風：Planka 2.2 才剛把 OIDC 塞進 Pro 版、Portainer 3.0 直接把 Community Edition 凍在 2.45 LTS、Grist 1.7.18 把 SSO 從 CE 拿掉，開源專案把身份驗證當付費入口這條線在 2026 上半年已經被拉得很清楚。Stirling PDF 反著走——把驗證這一段放給大家，卻在同一個版本新加了一組 PDF Processor 自動化系統，並設定每月 1000 份的免費配額。SSO 稅這條線沒有消失，只是換了收費的出口。
這是一次值得看細節的定價換手。免費的部分變多、付費的邊界也重畫了一遍，自架端如果只看標題就直接升級，很容易把原本免費的批次處理流程踩進配額裡。
過去半年 SSO 稅這條線是怎麼被拉出來的
2026 上半年幾支自架端熟面孔的更新方向高度一致：把身份整合搬進付費層。Planka 2.2 拿掉了 CE 版的 OIDC，Portainer 3.0 明確宣告 Community Edition 停留在 2.45 LTS 到 2027 年 5 月、之後不再有 CE 主線，Grist 1.7.18 也把 SSO 從免費版本移除。這幾個變動的商業邏輯一模一樣：小團隊用個人帳號沒差，企業要接 Keycloak、Authentik、Azure AD 就是要付費——這條「SSO 稅」線在 2025 年 GitLab、Sentry 上就走過一遍，2026 輪到中型自架工具跟進。
Stirling PDF 這次的方向反著：OAuth2 SSO 從此對 Free、Team、Enterprise 三層都開放，任何自架實例只要在 settings.yml 加 provider 設定就能跑。企業客戶付費才拿到的是 SAML2、air-gapped 部署、Uptime SLA 這幾樣真正的企業級要件。單純想接 Authentik 或 Keycloak 讓內部同事用 SSO 進去操作 PDF 這個場景，3.0 之後不用再多付錢。
3.0 這一版反著走的兩處挪動
真正的定價換手在 PDF Processor 這個新加的自動化模組。Processor 讓 Stirling PDF 把原本手動點按的工具拉成 pipeline，能接資料夾、FTP、S3 這類外部來源，做全庫 OCR、批次壓縮、大量格式轉換這類自動化任務——換句話說，Stirling PDF 從一個「Web 版 PDF 工具箱」升成「PDF 處理平台」。
新的計費規則寫得直白：Processor、API、AI 三條路徑的操作合計每月 1000 份 PDF 免費。額度用完之後要繼續跑，要嘛把實例綁定到 stirling.com 帳號多換 500 份配額加 hosted AI，要嘛升級 Team 方案（$99/月或 $999/年，100 個使用者、可用 100 為單位加購）。單獨的 PDF Editor 手動操作不列入計數，維持不限量免費——也就是說開放給使用者上網頁拖拉合併、拆頁、加浮水印這種互動場景不會踩到配額，只有走 API 或 Processor 才算。
這組換手的算式其實蠻透明：SSO 這種帳號整合是所有規模都會用到、擋掉會流失小型用戶的功能；批次自動化是企業或有量的部署才會用到、擋一點對個人用戶沒差。從留存跟商業轉換的角度都合理，但對自架 operator 來說，要重新盤點的是：目前用不用 API、跑不跑批次流程、有沒有寫過 cron 定時處理 PDF——這些場景在 3.0 之後不再是隱形免費，會計入 1000 份的月配額。
Processor 這 1000 份配額實際上會不會踩到
要判斷會不會踩到配額，看的是「操作」而不是「頁數」——一份 100 頁的 PDF 走一次 OCR 算一份。以中小型辦公室常見的情境估算，1000 份/月大致覆蓋這幾種用途：每天處理 30 份合約掃描檔 OCR、每週轉換 200 份簡報成 PDF、內部文件庫每月一次全量重新壓縮 300 份——這些個別看都在配額內，全部疊在同一個實例上就會超。
超過的處理方式有三條，各自的取捨不同：綁定 stirling.com 帳號多 500 份配額聽起來便宜，但代價是要把使用資料回傳給雲端；升 Team 方案 $99/月拿到的不只是額度上限，還多了外部資料庫支援、Google Drive 整合、Email 客服——對真的有量的環境比較划算；第三條是把重度自動化流程搬出 Stirling PDF、用 ghostscript、qpdf、tesseract 自己組 pipeline 走原生 CLI，Processor 只留給少量互動性強的任務。
第三條看起來比較土，但對純粹的批次處理場景效率反而最高。Stirling PDF 的強項一直是 GUI 好用、工具齊全這兩件事，跑無人值守的 pipeline 用 Python + PyPDF2 + ocrmypdf 直接寫，處理速度跟穩定度都會勝過任何 Web 前端層。3.0 的 Processor 適合的位置是「已經在 Stirling PDF UI 裡設計好的流程直接自動化」，不是「取代所有 PDF 批次處理」。
Team 跟 Enterprise 分層真正卡住的其實是這幾件事
翻一遍 3.0 的付費對照表，除了自動化配額之外還有幾個容易被忽略的邊界值得標出來。
外部資料庫在 Free 版本被鎖死，內建的 H2 embedded database 在單機少量使用者情境下沒問題，但要接 PostgreSQL 或 MariaDB 讓多台 Stirling PDF 共用一份使用者資料，得升 Team。這個限制對規模超過幾個部門的自架環境影響不小——想做 HA 部署得付費才行。
Google Drive 整合、Email 客服、法律協議這幾項也綁在 Team 上。SAML2 SSO（Okta、Azure AD 這類企業 IdP）留在 Enterprise 層——OAuth2 免費、SAML2 收費這個切法在自架 SaaS 圈子已經是慣例，Stirling PDF 只是照著走。air-gapped 部署要 Enterprise，這個對合規性嚴格的環境是硬需求。
License 模型是按 installation 計費、綁機器指紋——換句話說開 5 個 Stirling PDF 實例就要買 5 份 Team。這比較適合單一實例服務全公司、不太適合微服務化多實例部署的架構。要跑多實例的環境要嘛全走 Free（接受 5 人上限跟自動化配額）、要嘛談 Enterprise volume 折扣。
自架端 3.0 該怎麼配才不會被反噬
給典型自架環境的實務建議：Docker 一鍵拉起 3.0、settings.yml 加上 OAuth provider 設定（指向自架的 Authentik 或 Pocket ID）、SYSTEM.enableCloudFeatures=false 明確關掉雲端整合避免被動綁定 stirling.com。這樣就有完整的 SSO、Editor 全功能、API 跟 Processor 前 1000 份/月都能用。
進一步的細節是把 API 呼叫跟 Processor 任務單獨監控。Stirling PDF 3.0 在 Settings > Usage & Billing 面板會顯示當月配額使用進度，把這個 endpoint 接進 Prometheus 或 Uptime Kuma 監控、設個 800 份預警值，比等到 1000 份被擋才反應要輕鬆。對於原本就有 cron job 每晚批次處理 PDF 的環境，升 3.0 之前要把這批工作的月量估過一次，超過的先評估搬去用原生 CLI 工具。
想跑多實例做 HA 又想要外部 PostgreSQL 的組合，這一版沒有便宜的路——要嘛付 Team、要嘛用 nginx/HAProxy 前端加 sticky session 讓多台 Free 實例共存但接受各自獨立的使用者資料。後者 hacky 但可行，看得起使用者資料一致性的要求。
這條 SSO 稅的線接下來會怎麼走
Stirling PDF 3.0 的定價換手值得放在一個更大的脈絡看。2025 到 2026 中期，開源自架端 SaaS 化的商業實驗是「把 SSO 收進付費層」，2026 下半年開始出現的反向嘗試（Stirling PDF 是最明顯的一支）是「SSO 放給大家、把自動化跟配額收起來」。哪一條會贏還早，但對自架 operator 來說要意識到：付費牆的位置會動，升級之前要仔細看的是「這一版把什麼從免費變收費」，不是「這一版新加了什麼功能」。
NCSE Network 的臺灣 VPS 拿來跑 Stirling PDF 3.0 剛好
Stirling PDF 3.0 的容器化部署對 VPS 的要求不算高：2 vCPU 4GB RAM 就能跑起完整的 Editor 加低量 Processor，如果同時把 Authentik 或 Pocket ID 疊在同一台上做內部 SSO 樞紐，4 vCPU 8GB 是比較舒服的起點。NCSE Network 提供的 VPS 主機跑在臺灣是方電訊機房、Intel Gold CPU 加 NVMe SSD，Debian 13、Ubuntu 26.04 這些主流映像檔開機即用，Docker 環境跟 Compose 檔上傳即跑。想了解相關方案細節，可以到 ncse.tw 查看。
