Por qué nos saltamos la app de escritorio

Cuando los archivos no deben salir de una red privada, la siguiente petición suele ser un instalador para Windows o macOS. Rechazamos esa forma a propósito. Una interfaz gráfica de escritorio sería una segunda base de código de interfaz. La deriva de funciones entre «la aplicación» y /api/v1/ es casi inevitable en cuanto esos árboles se separan.

La restricción es el límite, no la apariencia

«Los bytes se quedan aquí» se cumple con un pdfx-server que ejecutas tú, no con WinForms o Electron en concreto. Compose más pdfx (local o --cloud contra tu URL base) mantiene un único catálogo de operaciones detrás del navegador, REST, MCP y el CLI.

Cómo levantar ese stack está documentado en Self-host: task docker:build / task docker:up para Compose (API en :8080, portal en :3000), o task pdfx:dev nativo junto al portal para el trabajo local. Define SECURITY_CUSTOMGLOBALAPIKEY cuando quieras una puerta fija. Este artículo solo explica por qué ese stack no se envuelve como producto de escritorio.

El pdfx local sin --cloud ejecuta pdf-core en la máquina que tiene los archivos. Eso ya cubre los trabajos por lotes offline que nunca necesitaron una interfaz gráfica. El modo cloud sirve para cuando el mismo CLI debe llamar a tu base de API autoalojada o alojada con el mismo contrato multipart que curl.

Qué costaría una versión de escritorio

Las suites de consumo optimizan la edición en lienzo, la comparación visual y los instaladores de tienda. Mantener esa superficie obliga a duplicar cada nueva op (flags de combinación, modos de OCR, valores de sanitización) en una interfaz que no es el contrato OpenAPI que los agentes ya llaman.

Los plugins y los canales de tienda multiplican el soporte sin mejorar el comportamiento de MCP o de Idempotency-Key. Cada ciclo de revisión de una tienda y cada aviso de permisos del sistema es tiempo que no llega a /v1/openapi.json. En cuanto el árbol de escritorio publica una opción de combinación que la API no tiene (o al contrario), las automatizaciones y las demostraciones discrepan en silencio.

El OCR es un ejemplo concreto de por qué duele duplicar. La ruta actual del servidor devuelve Markdown (text/markdown) con modos Auto y Force (ocrType=force-ocr para Force). Una interfaz de escritorio que siguiera prometiendo «PDF buscable con capa oculta» estaría mintiendo sobre otro proceso. Mantener una sola definición de op evita esa escisión.

Un catálogo, cuatro clientes, ninguna segunda interfaz

El producto ya tiene cuatro manejadores sobre las mismas ops: el formulario del portal, curl a /api/v1/…, MCP en /mcp y pdfx en local o cloud. Combinar es el ejemplo concreto: unir PDF en orden de subida sin rasterizar las páginas a imágenes, tanto si pulsaste Process como si enviaste partes fileInput.

Una edición de escritorio sería un quinto manejador con su propio ciclo de publicación. El modo de fallo que nos importa no es «falta un icono en la bandeja», sino «la página de demostración sigue funcionando mientras el script que dependía de la misma op se rompe en silencio».

Qué no afirmamos

Saltarnos el escritorio no crea edición interactiva de nivel Acrobat en el navegador. Las herramientas de formulario y los trabajos HTTP siguen siendo el producto. Los lienzos de edición online, la comparación visual y las interfaces de firma para consumidores quedan fuera de alcance a propósito. Si necesitas un despliegue privado, levanta Compose y apunta los clientes a tu base de API. Si necesitas un editor de píxeles, usa una suite hecha para eso; no esperes un .exe de PDF123.

El PDF123 alojado sigue siendo la vía anónima rápida. El autoalojamiento es el mismo toolkit detrás de tu cortafuegos. Ninguna de las dos es una tercera edición de escritorio divergente. Para el contraste con los convertidores solo-navegador, consulta Por qué autoalojar un toolkit PDF. Para saber qué compras y qué operas, consulta Qué te compra realmente el self-hosting. Para ver cómo se alinean los cuatro clientes sin escritorio, consulta La misma operación, cuatro clientes.