為什麼要自架 PDF 工具箱，而不是再找一個免費網頁轉換器

純瀏覽器端的 PDF 轉換器，最佳化的就是上傳、點一下、下載。頁面往往靠廣告支撐，表單之外通常也沒有穩定的開發者介面。這種產品形態對「人手做一次」是對的；一旦你需要自動化、留存政策，或檔案必須留在自己的網路裡，它就不對了。

瀏覽器轉換器在最佳化什麼

公開轉換器賣的是方便：開一個分頁、丟進檔案、拿到結果、走人。UI 本身就是產品。腳本只能去爬 HTML，或去打那些未文件化、還會無預警變更的端點。暫存檔留多久，取決於營運那個空間的人。若只是把兩份個人 PDF 合併一次，這筆交易可以接受。

一旦你要從 CI、Agent 或氣隙網路跑同一份工作，缺少的東西會同時冒出來：認證、OpenAPI、可冪等的重試，以及一份不會和上週點過的表單悄悄分叉的工具目錄。

自己跑這份目錄能得到什麼

代管網站與自架實例共用同一批操作。壓縮 與 合併 無論請求來自入口網站還是 POST /api/v1/…，都是同一批 op。自架是在這份共享目錄外圍加上控制：

• REST + OpenAPI（/v1/openapi.json）：每個目錄工具都是穩定端點，不只是表單。
• MCP（/mcp）：Agent 可以發現並呼叫同一批操作，不必自己發明爬蟲。
• CLI（pdfx）：本機 pdf-core，或用 --cloud 對準你 base URL 上的 API Key。
• 沒有桌面用戶端：離線的答案是 Docker Compose；外掛與 Windows 安裝程式刻意不在範圍內。
• 廣告不進你的堆疊：公網站的 AdSense 不屬於自架部署。上傳不會離開你實際在跑的機器。

Compose 會一起拉起 Rust pdfx-server 與 Next.js 入口網站，讓人和腳本共用一份目錄。原生開發（task pdfx:dev 加上入口網站）走同一條 op 路徑。細節見 自架。

任一部署上的 OCR 仍從 /api/v1/misc/ocr-pdf 回傳 Markdown（text/markdown），不是重新疊上文字層的可搜尋 PDF。把伺服器搬到別處只改變位元組落在哪，不會變出一份不同的 op 契約。

我們刻意不抄的部分

線上「編輯 PDF」畫布、視覺化比對、空白的建立 PDF，以及消費級簽名介面，需要另一套產品工作。我們保留以表單為主的工具矩陣與 API。自架不會解鎖第二棵 UI 樹，它只是把同一棵樹移到你的防火牆後面。

跳過這些消費級介面是刻意的。畫布編輯器會變成第二套程式碼庫，功能永遠落後 OpenAPI。私有用途真正要緊的約束是「位元組留在這裡」，不是「有一個 .exe」。為什麼沒有桌面分叉，見 為什麼我們不做桌面應用。

什麼時候代管就夠，什麼時候不夠

要零設定、匿名一次性的時候，用公開網站。目錄工具與匿名 /api/v1/ 呼叫不需要帳號；代管回應會帶上限流標頭，設上限是為了不讓免費介面變成別人的批次農場（匿名限流）。

需要留存規則、私有網路或私有自動化時，就自架。這時你得自己負責可用性、映像升級、暫存檔的磁碟、TLS 與金鑰輪替（本機固定閘門用 SECURITY_CUSTOMGLOBALAPIKEY）。操作不變，變的是位元組落在哪裡。

試一下

從 自架 與 開發者 起步。任一 base URL 上面向 Agent 的 API 介面，見 為 AI Agent 而建，不只為瀏覽器。更長的成本效益拆分，見 自架實際買到什麼。