Lo que un cPanel compartido puede y no puede correr

Todos los sistemas del catálogo de AppsSDAR corren sobre un cPanel compartido, no sobre un clúster de servidores dedicados. Es una decisión consciente de costo, y funciona bien para lo que necesita la mayoría de estos proyectos — pero solo si conoces exactamente qué puede y qué no puede correr ahí antes de diseñar, no después.

Lo que sí hay

Un cPanel moderno con CloudLinux ofrece más de lo que parece a primera vista: varias versiones de PHP, Node y Python instaladas y seleccionables por dominio, PostgreSQL y MariaDB, y binarios básicos como ImageMagick y Ghostscript. Para sitios estáticos, aplicaciones Node livianas o backends en PHP y Python, es perfectamente viable, y sale varias veces más barato que levantar un servidor dedicado para cada proyecto.

Lo que casi nunca está, y sorprende cuando falta

ffmpeg, poppler-utils, tesseract (OCR) y LibreOffice — por nombrar los más comunes— casi nunca vienen instalados en un hosting compartido, y no hay acceso de root para instalarlos por fuera del selector de paquetes del panel. Si un proyecto asume que puede convertir video, extraer texto de un PDF escaneado o pasar un Word a PDF desde el servidor, ese supuesto se cae el día del despliegue, no antes — y para entonces ya es tarde para replantear la arquitectura sin perder tiempo.

La salida que uso: mover el trabajo al navegador

Cuando el binario que falta es para procesar algo que el usuario mismo sube —una imagen, un PDF, un video corto— la solución que mejor me ha funcionado no es pelear por instalar el binario, sino evitar necesitarlo: procesar ese archivo directamente en el navegador con WebAssembly. Es exactamente la arquitectura detrás de Arca y sobre todo de Utilitarios, donde escribí con más detalle por qué ningún archivo sube a un servidor. Cuando eso no es posible —por ejemplo, con dependencias nativas de Node como sharp para imágenes— conviene probar la instalación por SSH antes de comprometerse: algunos paquetes traen binarios precompilados que sí funcionan sin compilar nada en el servidor, y otros intentan compilar desde el código fuente y fallan o tardan demasiado en un entorno compartido.

Los límites que no son de software: NPROC y memoria

Un cPanel compartido reparte CPU, memoria y número de procesos entre todas las cuentas del mismo servidor físico mediante un sistema de cuotas (LVE, en CloudLinux). Cada aplicación Node que dejas corriendo consume una porción fija de esa cuota de procesos, así que levantar una app Node separada por cada funcionalidad pequeña se come el límite rápido. Preferir sitios estáticos o un solo proceso Node que sirva varias rutas, en vez de un microservicio por feature, alarga mucho más la vida útil de la cuenta antes de necesitar upgrade.

Cuándo dejar de pelear y migrar

El punto de quiebre no es "cuando algo no funciona una vez": es cuando el proyecto necesita, de forma estructural, algo que el hosting compartido no puede dar —un proceso en segundo plano persistente, Redis, Docker, o simplemente más CPU dedicada de la que la cuota permite sin afectar a los demás sistemas que comparten el mismo servidor. Ahí la respuesta ya no es un workaround, es un VPS con un orquestador propio. Para todo lo demás —que es la mayoría de lo que construyo— el hosting compartido, bien entendido, es la opción más barata y más que suficiente.