Cómo autoalojar Stirling PDF en 2026: cargas, OCR y seguridad del inicio de sesión
Autoalojar Stirling PDF con puertos correctos, almacenamiento persistente, HTTPS, secretos, copias de seguridad y comprobaciones de actualización. Aprende a solucionar los casos en que las cargas superan el límite del proxy.
Hay dos versiones de «ejecutar Stirling PDF»: existe un contenedor o el servicio completa su función real. Solo importa la segunda. Aquí, la prueba consiste en combinar dos PDF, aplicar OCR a una página escaneada, comprimir el resultado y verificar el comportamiento de carga y descarga a través del proxy público.
Stirling PDF sirve para esto: ofrece una interfaz web y una API para operaciones habituales con PDF. El despliegue debe conservar los elementos que hacen posible ese comportamiento; un puerto, un volumen y un certificado son entradas, no el resultado.
Configuración del contenedor que conviene revisar
El primer contenedor debe poder eliminarse y recrearse fácilmente. Mantén los datos fuera de la capa escribible, vincula el puerto 8080 solo donde el proxy pueda acceder a él y pasa la configuración en tiempo de ejecución.
docker run -d \
--name stirling-pdf \
--restart unless-stopped \
-p 127.0.0.1:8080:8080 \
-v stirling-pdf-data:/configs \
-e SECURITY_ENABLELOGIN=true \
stirlingtools/stirling-pdf:latest
Fija la imagen después de la prueba inicial. Lee el primer error de arranque en lugar del mensaje final de reinicio, verifica cada montaje con docker inspect y sigue los logs mientras combinas dos PDF, aplicas OCR a una página escaneada, comprimes el resultado y verificas el comportamiento de carga y descarga a través del proxy público. Esta secuencia permite distinguir un comando de imagen incorrecto de un problema de dependencias o permisos.
Define primero el éxito de Stirling PDF
Separa cuatro aspectos de Stirling PDF: la entrada, el listener en 8080, el estado persistente y los servicios auxiliares o la capacidad local. El requisito del entorno local es disponer opcionalmente de datos de idiomas para OCR y de suficiente espacio temporal en disco para trabajos grandes. Regístralo junto a la imagen y el puerto para que un host de reemplazo reciba la misma capacidad local.
Ejecuta la transacción validada —combinar dos PDF, aplicar OCR a una página escaneada, comprimir el resultado y verificar el comportamiento de carga y descarga a través del proxy público— antes de dar por completada esa separación. Mide el espacio temporal en disco, los paquetes de idiomas para OCR, la memoria de la JVM y el número de trabajos de conversión simultáneos, y conserva el resultado junto con el registro del despliegue. Esto proporciona tanto un criterio de aceptación como la primera referencia de capacidad.
Protege Stirling PDF después del bootstrap
El riesgo de seguridad específico de la aplicación consiste en dejar desactivada la seguridad en un servicio público de procesamiento de documentos. La respuesta operativa es activar el inicio de sesión en una instancia expuesta a Internet y evitar conservar los documentos cargados durante más tiempo del necesario para el trabajo. Completa el bootstrap mediante una ruta restringida y elimina inmediatamente después el acceso temporal de configuración.
SECURITY_ENABLELOGIN controla el comportamiento, no la confidencialidad; valida su tipo y valor, y almacena por separado las credenciales reales de Stirling PDF. Concede al proceso de Stirling PDF únicamente los montajes y las rutas de dependencia documentados; evita el acceso al directorio raíz del host y al socket de Docker. Registra los fallos de autenticación y los errores de configuración, pero redacta los tokens, las cadenas de conexión y el contenido de los usuarios.
Proporciona a Stirling PDF una única dirección canónica
El navegador, el cliente de la API y Stirling PDF deben coincidir en un único origen. Para conseguirlo, configura el origen HTTPS público y los límites de carga del proxy. Conserva el host y el protocolo originales, y evita que el puerto 8080 quede disponible como una dirección pública alternativa.
La guía de resolución de problemas cuando el sitio está caído ayuda a distinguir una ruta inaccesible de una aplicación que responde. Esta diferencia es importante aquí: las cargas superan el límite del proxy o el contenedor no puede escribir archivos temporales. Solo el primer caso se soluciona con cambios en la entrada; el segundo requiere revisar los logs, el estado o la carga de trabajo de Stirling PDF.
Separa los contenedores reemplazables de los datos persistentes
El conjunto de recuperación persistente incluye la configuración, los archivos personalizados y cualquier dato de OCR que hayas instalado deliberadamente. Monta /configs antes del bootstrap, escribe datos de ejemplo inofensivos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Un volumen protege los datos frente al reemplazo del contenedor, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.
Haz copias de seguridad que entiendan el origen de los datos: usa volcados lógicos para bases de datos activas cuando sea necesario y copia archivos solo desde un estado coherente. Conserva una copia cifrada fuera del host de Stirling PDF. El criterio de aceptación de una restauración debe ser específico: la configuración y los recursos de OCR deben recuperarse, y un documento de prueba fijo debe producir un resultado aceptable y legible. La guía sobre copias de seguridad que se han restaurado explica por qué el éxito del trabajo por sí solo no es suficiente.
Recopila evidencias antes de poner Stirling PDF en producción
Para Stirling PDF, define una transacción validada antes del lanzamiento: combina dos PDF, aplica OCR a una página escaneada, comprime el resultado y verifica el comportamiento de carga y descarga a través del proxy público. Guarda sus requisitos previos, la respuesta esperada y los pasos de limpieza en el control de versiones, sin valores secretos. Fija la imagen utilizada para establecer esa referencia.
Usa la transacción para validar un reemplazo y una restauración independiente. El servicio restaurado solo es aceptable cuando la configuración y los recursos de OCR se recuperan, y un documento de prueba fijo produce un resultado aceptable y legible. Al mismo tiempo, observa el espacio temporal en disco, los paquetes de idiomas para OCR, la memoria de la JVM y el número de trabajos de conversión simultáneos, y convierte la parte más lenta o más limitada en una alerta de nivel de servicio.
El criterio también necesita un caso negativo: envía una entrada inofensiva cercana al límite de recursos o formato asociado con este límite: las cargas superan el límite del proxy o el contenedor no puede escribir archivos temporales. Confirma que Stirling PDF produce un error útil sin perder datos, restaura la condición válida y repite la transacción validada. Conservar ambos resultados evita que un endpoint de estado superficial se convierta en la única evidencia en producción.
Opera Stirling PDF en torno a su cuello de botella real
Observa el trabajo que realiza Stirling PDF: el espacio temporal en disco, los paquetes de idiomas para OCR, la memoria de la JVM y el número de trabajos de conversión simultáneos. Establece límites con margen suficiente para ese trabajo y evita una sonda de liveness que compita con él. La comprobación del operador debe seguir intentando combinar dos PDF, aplicar OCR a una página escaneada, comprimir el resultado y verificar el comportamiento de carga y descarga a través del proxy público de forma programada.
Para las actualizaciones, recuerda que los datos de OCR instalados, la configuración personalizada y los ajustes de seguridad deben compararse antes de actualizar una imagen. Despliega la versión candidata sobre una copia recuperada y repite la prueba validada. Si las cargas superan el límite del proxy o el contenedor no puede escribir archivos temporales, utiliza los logs de ejecución y la solicitud de red real para determinar qué supuesto ha cambiado.
Despliega Stirling PDF en Dockup sin perder sus límites
Dockup elimina el trabajo manual de reverse proxy y del ciclo de vida en torno a Stirling PDF. El servicio recibe una ruta HTTPS estable hacia 8080, configuración inyectada y almacenamiento persistente durante los reemplazos. Un servidor del cliente conectado sigue el mismo modelo que el cómputo alojado en Dockup.
Después del lanzamiento, cumple el contrato de la aplicación: configura el origen HTTPS público y los límites de carga del proxy, confirma el requisito local —datos opcionales de idiomas para OCR y suficiente espacio temporal en disco para trabajos grandes— y ejecuta esta prueba: combina dos PDF, aplica OCR a una página escaneada, comprime el resultado y verifica el comportamiento de carga y descarga a través del proxy público. Esto mantiene útil la experiencia de un solo clic sin ocultar los detalles que hacen que Stirling PDF sea recuperable y seguro.
Preguntas frecuentes
¿Qué necesita Stirling PDF para un despliegue en producción?
Enruta el contenedor de Stirling PDF en el puerto 8080 a través de un único origen HTTPS. El requisito del entorno local es disponer opcionalmente de datos de idiomas para OCR y de suficiente espacio temporal en disco para trabajos grandes. No consideres que Stirling PDF está listo hasta que puedas combinar dos PDF, aplicar OCR a una página escaneada, comprimir el resultado y verificar el comportamiento de carga y descarga a través del proxy público.
¿Qué datos de Stirling PDF deben incluirse en una copia de seguridad?
Haz persistir /configs e incluye la configuración, los archivos personalizados y cualquier dato de OCR que hayas instalado deliberadamente en el mismo manifiesto de recuperación. Una restauración limpia de Stirling PDF solo es válida cuando la configuración y los recursos de OCR se recuperan, y un documento de prueba fijo produce un resultado aceptable y legible.
¿Stirling PDF necesita HTTPS detrás de un reverse proxy?
Usa HTTPS para el origen público de Stirling PDF y mantén el puerto 8080 en la ruta interna. Aplica correctamente la configuración de Stirling PDF: establece el origen HTTPS público y los límites de carga del proxy. En Stirling PDF, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.
¿Cómo debe probarse una actualización de Stirling PDF?
Restaura el estado actual de Stirling PDF en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque los datos de OCR instalados, la configuración personalizada y los ajustes de seguridad deben compararse antes de actualizar una imagen. Conserva la imagen anterior de Stirling PDF hasta comprender los límites de migración de datos y rollback.