自托管实际买到什么，以及要付出什么
自托管 PDF123 让上传落在你自己的 pdfx-server 上，同一套 REST、MCP 与 CLI 目录都归你，代价是全部的运维责任。
公网转换器优化的是匿名一次性任务。自托管 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）。
带上你的 Key 的 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。
限流与计量行为取决于你怎么配置这台机器。别假设公网站对外标示的响应头和额度会原样搬过来；在意预算时，读你自己实例返回的头。依赖较重的 op（OCR 模型、可选转换器）在镜像里没有对应二进制或模型包时，会以结构化的 missing_dependency / unavailable problem 码失败。
它与公网站的关系
零配置试用就用托管 PDF123。那里的目录工具和匿名 /api/v1/ 调用都不需要账号；响应会带 X-RateLimit-*，429 响应里还有 Retry-After（匿名限流）。
有留存规则、气隙网络或私有自动化要求时再自托管。/llms.txt 帮 Agent 在你运行的任一 base URL 上发现工具；Google 搜索并不把它当作排名信号。MCP 与 OpenAPI 仍与门户并列，挂在同一个 base 上。
什么时候先别自托管
如果你只是今天下午要合并一份文件，托管表单就够了。如果你从明天起、并且往后每天都需要私有字节，那就现在从 Compose 起步，而不是把桌面安装包硬接到 SaaS 习惯上。我们支持的离线方案写在自托管页面上，而不是某个应用商店的条目里。
从自托管起步。Key 与 OpenAPI 在开发者。想看清与纯浏览器转换器的差别，见为什么自托管 PDF 工具箱。为什么私有路径是 Compose 而不是 .exe，见为什么我们不做桌面应用。