自架實際買到什麼（以及要付出什麼）

公開轉換器最佳化的是匿名的一次性作業。自架 PDF123 改掉的則是契約本身：上傳落在你自己營運的機器上，而且目錄裡每個工具都能以 HTTP 觸及，不再只是一張瀏覽器表單。

你買到什麼

第一筆買到的是資料在地性。檔案打到你的 pdfx-server，不是一個不由你營運的暫存空間。第二筆是同一台機器上的開發者介面：/api/v1/… 下的 REST、/v1/openapi.json 的 OpenAPI、/mcp 上的 MCP，以及把 base URL 指向你的 pdfx --cloud。

Docker Compose 會把 Rust 後端與 Next.js 入口網站一起跑起來，讓人和腳本共用同一份目錄。這條路徑裡沒有桌面安裝程式；離線使用就是 Compose 加 CLI（自架）。本機原生開發用 task pdfx:dev，與入口網站並排跑；Compose 用 task docker:build／task docker:up（API 在 :8080，入口網站在 :3000）。

帶著你的金鑰的 Agent 或 CI 工作，呼叫的是和公開網站完全相同的 op。合併、壓縮、OCR、轉換以及其他工具都維持同樣的路徑與參數。這種一致性本身就是產品，不是一句口號。

支撐公開網站的廣告不屬於自架部署的一部分。同時你也跳過了代管端的匿名配額問題：容量規劃變成你自己的事，包括 OCR 或大型合併期間的 CPU 尖峰。OCR 在你的機器上仍回傳 Markdown（text/markdown）；把伺服器換個位置，不會改變 op 契約。

你要付出什麼

可用性、映像升級、暫存檔的磁碟、TLS 與金鑰輪替，都歸你。Compose 啟動很快，讓它保持健康則是長期工作。想在自己的實例上加一道固定 API Key 閘門，就設定 SECURITY_CUSTOMGLOBALAPIKEY。可選功能（例如用 SYSTEM_ENABLEURLTOPDF=true 開啟 URL→PDF）是你刻意啟用的旗標，不會因為公開網站有就自動冒出來。

自架也不會靠翻一個旗標就多出視覺化的「編輯 PDF」畫布。介面仍然是表單工具加 API。如果你需要畫布編輯，還是得換一個產品；搬動伺服器變不出那套 UI。

限流與計量行為取決於你如何設定這台機器。不要假設公開網站對外宣告的標頭與上限會原樣移植過來；在意額度時，讀你自己實例回傳的標頭。依賴較重的工作（OCR 模型、可選轉換器）若映像裡沒有對應的二進位檔或模型包，會以結構化的 missing_dependency／unavailable problem 碼失敗。

它與公開網站的關係

零設定試用請用代管的 PDF123。那裡的目錄工具與匿名 /api/v1/ 呼叫都不需要帳號；回應會帶 X-RateLimit-*，429 回應裡也有 Retry-After（匿名限流）。

有留存規則、氣隙網路或私有自動化需求時，再自架。/llms.txt 能幫 Agent 在你運行的任何 base URL 上發現工具；Google 搜尋並不把它當成排名訊號。MCP 與 OpenAPI 依然與入口網站並列在同一組 base 上。

什麼時候還不必自架

如果你只是今天下午要合併一份文件，代管表單就夠了。如果你從明天起、往後每天都必須有私有位元組，那就現在從 Compose 起步，而不是把桌面安裝程式硬接在 SaaS 習慣上。我們支援的離線方案寫在 自架 文件裡，不是某個商店頁面。

從 自架 起步。金鑰與 OpenAPI 在 開發者。想看清與純瀏覽器轉換器的差別，見 為什麼要自架 PDF 工具箱。為什麼私有路徑是 Compose 而不是 .exe，見 為什麼我們不做桌面應用。