セルフホストが実際にもたらすもの（と、そのコスト）

公開コンバータは匿名の単発作業に最適化されている。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）。

自分のキーを持つエージェントや 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 は、どの base URL で動かしていてもエージェントのツール発見を助ける。Google Search はこれをランキングシグナルとして扱わない。MCP と OpenAPI は、その同じ base のポータルの隣で利用できる。

まだセルフホストすべきでないとき

今日の午後に一回結合するだけなら、ホスト版のフォームで足りる。明日もその先も毎日プライベートなバイトが必要なら、SaaS の習慣にデスクトップインストーラーを継ぎ足すより、今から Compose で始めた方がよい。私たちが支えるオフラインの解は セルフホスト に文書化されており、ストアの出品ではない。

セルフホスト から始める。キーと OpenAPI は 開発者向け にある。ブラウザ専用コンバータとの短い対比は PDF ツールキットをセルフホストする理由。プライベートな経路が .exe ではなく Compose である理由は デスクトップアプリを作らない理由 にある。