Зачем самостоятельно хостить PDF-набор, а не брать ещё один бесплатный веб-конвертер

Браузерные PDF-конвертеры оптимизированы под сценарий «загрузить, нажать, скачать». Реклама часто оплачивает страницу, а стабильной поверхности для разработчика, кроме формы, обычно нет. Такая форма продукта правильна для разовой задачи, которую делает человек. Она неправильна, когда нужны автоматизация, политика хранения или файлы, которые обязаны остаться в вашей сети.

Под что оптимизированы браузерные конвертеры

Публичный конвертер продаёт удобство: открыть вкладку, перетащить файл, получить результат, уйти. Интерфейс и есть продукт. Скриптам остаётся либо парсить HTML, либо обращаться к недокументированным эндпоинтам, которые меняются без предупреждения. За хранение отвечает тот, кто держит временное хранилище. Для одного слияния двух личных PDF такой обмен выгоден.

Как только та же задача нужна из CI, агенту или сети без выхода в интернет, недостающие части проявляются сразу: аутентификация, OpenAPI, идемпотентные повторные попытки и каталог, который не расходится незаметно с формой, по которой вы кликали неделю назад.

Что вы получаете, запуская этот каталог у себя

Хостинговый сайт и развёрнутый самостоятельно экземпляр разделяют одни операции. Сжатие и слияние — те же операции, пришёл запрос из портала или из POST /api/v1/…. Самостоятельный хостинг добавляет контроль вокруг этого общего каталога:

• REST + OpenAPI на /v1/openapi.json: каждый инструмент каталога — стабильный эндпоинт, а не только форма.
• MCP на /mcp: агенты находят и вызывают те же операции, не изобретая парсеры.
• CLI (pdfx): локальный pdf-core или --cloud против API-ключа на вашем базовом URL.
• Без настольного клиента: офлайн-сценарий — это Docker Compose; плагины и установщики для Windows намеренно вне области.
• Реклама не на вашей стороне: AdSense на публичном сайте не входит в самостоятельное развёртывание. Загрузки не покидают машины, которые вы запускаете.

Compose поднимает вместе Rust-сервер pdfx-server и портал на Next.js, чтобы люди и скрипты работали с одним каталогом. Нативная разработка (task pdfx:dev плюс портал) идёт по тому же пути операций. Подробности на Self-host.

OCR в любом развёртывании по-прежнему возвращает Markdown (text/markdown) из /api/v1/misc/ocr-pdf, а не PDF с заново наложенным слоем поиска. Перенос сервера меняет место, куда попадают байты; он не создаёт другой контракт операций.

Что мы намеренно не копируем

Онлайн-редакторы «Edit PDF», визуальное сравнение, пустое создание PDF и потребительские интерфейсы подписи требуют другой продуктовой работы. Вместо них мы держим матрицу инструментов на основе форм и API. Самостоятельный хостинг не открывает второе дерево интерфейса; он переносит то же дерево за ваш брандмауэр.

Пропускать эти потребительские поверхности — осознанно. Редактор-холст стал бы второй кодовой базой со своим отставанием в возможностях относительно OpenAPI. Ограничение, важное для приватного использования, — «байты остаются здесь», а не «есть .exe». О том, почему нет настольной версии, см. Почему мы отказались от настольного приложения.

Когда хостинга достаточно, а когда нет

Пользуйтесь публичным сайтом, когда нужно без настройки и разово, анонимно. Инструменты каталога и анонимные вызовы /api/v1/ не требуют аккаунта; ответы хостинга сообщают заголовки ограничения частоты, а лимиты существуют, чтобы бесплатная поверхность не превратилась в чужую пакетную ферму (анонимное ограничение частоты).

Разворачивайте у себя, когда этого требуют правила хранения, закрытые сети или приватная автоматизация. Тогда вы отвечаете за доступность, обновления образов, диск для временных файлов, TLS и ротацию ключей (SECURITY_CUSTOMGLOBALAPIKEY для фиксированного гейта на вашей машине). Операции остаются теми же; меняется то, где оказываются байты.

Попробуйте

Начните с Self-host и Разработчикам. О поверхности API для агентов на любом базовом URL читайте в статье Создан для AI-агентов, а не только для браузеров. О более подробном разделении затрат и выгод см. Что на самом деле даёт самостоятельный хостинг.