Next.js en cPanel: requisitos antes de migrar tu sitio

Primero identifica qué tipo de sitio tienes

cPanel es un panel de administración; por sí solo no confirma que un plan incluya Node.js ni que pueda mantener una aplicación Next.js en ejecución. La disponibilidad depende del servidor, los paquetes que instaló el proveedor, las funciones habilitadas para tu cuenta y los límites del plan. Application Manager usa Passenger; el proveedor puede activar o desactivar esa interfaz. cPanel también documenta Web Apps desde cPanel & WHM 138 en adelante, con el tema Meridian. Son rutas distintas de administración: pregunta cuál está disponible para tu cuenta y quién mantiene los paquetes del servidor.

Antes de elegir hosting, separa lo que ocurre al compilar de lo que debe ocurrir cuando alguien visita la página. Los componentes de servidor pueden generar contenido durante el build; eso no implica por sí solo que el sitio necesite Node en producción. En cambio, si la aplicación Next.js debe procesar solicitudes en el servidor, el destino debe ofrecer un runtime compatible. También puedes dejar la interfaz estática y conectar un backend externo, si el diseño y la seguridad del sistema lo permiten.

Next.js 16 requiere Node.js 20.9 o posterior. La documentación de cPanel enumera paquetes Node.js 20 y 22 para ciertos sistemas, pero eso no demuestra que estén instalados en tu servidor ni habilitados en tu paquete. Pide la versión exacta que recibirá el proceso y confirma que el gestor puede iniciarlo, reiniciarlo y mostrar sus registros. Revisa también memoria, CPU, procesos simultáneos, tareas programadas y disco.

Decide entre archivos estáticos y un servidor

La exportación estática genera una carpeta de archivos para servir con Apache u otro servidor web. La salida no conserva automáticamente las funciones que requieren ejecutar código de Next.js al recibir cada solicitud. Si habilitas la exportación con output: "export", Next.js genera la carpeta out/ al compilar; verifica antes que cada ruta y flujo del proyecto sea compatible.

La guía de Next.js permite exportar Route Handlers solo como respuestas estáticas GET; no permite los que dependen del objeto Request. También enumera como no compatibles en una exportación estática las cookies, Server Actions, Proxy, encabezados y redirecciones de Next.js, entre otras funciones. Para cada caso, compara tu implementación con la lista oficial de funciones no compatibles; algunas necesidades pueden resolverse en el servidor web o en un backend externo, pero esa adaptación también debe probarse.

Combina Next.js y cPanel por función

No hace falta que una sola cuenta ejecute todo el sistema. Si un proveedor sirve Next.js y tu cPanel ofrece PHP y MySQL, una opción es mantener la aplicación Next.js en su hosting actual y publicar una API PHP bajo un subdominio propio, por ejemplo api.ejemplo.com. El servidor de Next.js llama esa API por HTTPS; PHP accede a MySQL desde el mismo cPanel. El navegador nunca recibe las credenciales de la base.

Esta separación solo es viable después de confirmar que cPanel admite el dominio o subdominio, certificado HTTPS, una versión de PHP compatible y PDO MySQL. Las solicitudes de Next.js al servicio privado deben usar autenticación entre servidores; la API debe aceptar una lista pequeña de operaciones, validar cada campo y aplicar permisos mínimos. CORS no sustituye la autenticación, y MySQL no debe exponerse al público por el puerto 3306.

Separa las claves secretas de los archivos públicos y del repositorio. Revisa quién opera cada hosting, región de almacenamiento, copias de seguridad, conservación, contratos y registros antes de enviar datos de contacto o suscripción. Tener un puente PHP preparado en el repositorio no demuestra que esté instalado, conectado a una base o listo para recibir datos reales.

Para una cuenta que solo ofrece PHP/MySQL, este patrón puede alojar una API y la base de datos, pero no ejecuta el servidor Next.js. Para trasladar todo el sitio, primero confirma un runtime compatible o demuestra que cada ruta y API puede reemplazarse sin perder formularios, sesiones, correo, tareas programadas ni funciones privadas.

Preguntas concretas para el proveedor

Antes de subir código, solicita respuestas para el dominio exacto y el plan contratado. Que el menú de cPanel muestre una herramienta no garantiza que todas sus funciones estén instaladas o disponibles para tu usuario.

• ¿La cuenta del dominio permite ejecutar aplicaciones Node.js persistentes?
• ¿Qué versión de Node.js ofrecen y es igual o superior a 20.9?
• ¿Tienen Application Manager con Passenger o Web Apps habilitado para esta cuenta? Si ofrecen Web Apps, ¿el servidor usa cPanel & WHM 138 o posterior y el tema Meridian?
• ¿Qué archivo de inicio, ruta de aplicación y comando de despliegue esperan?
• ¿Qué límites de memoria, procesos, tiempo y disco aplican al proceso Node?
• ¿Cómo se configuran variables de entorno, dependencias nativas y la conexión saliente a base de datos o SMTP?
• ¿Se puede crear un subdominio de pruebas con HTTPS sin afectar el sitio activo?
• ¿Qué método recomiendan para trabajos programados, backups y consulta de registros de errores?

Guarda la respuesta del soporte. cPanel indica que el proveedor debe instalar los paquetes requeridos y puede activar o desactivar Application Manager. Si Node o Passenger no están habilitados, pide confirmación escrita de que pueden habilitarlos para el plan. Un Apache configurado solo para servir archivos no equivale a un destino para una aplicación Next.js con servidor.

Prepara una prueba aislada

1. Inventaría dependencias. Lista páginas, rutas API, formularios, base de datos, correo saliente, claves privadas, cargas de archivos, imágenes optimizadas y tareas cron. Distingue lo que se renderiza al compilar de lo que debe ocurrir cuando llega una petición. Marca cada función como estática, atendida por Next.js o delegada a otro servicio.
2. Conserva una salida de reversión. Respalda archivos, base de datos y configuración DNS actuales. Registra A, AAAA, CNAME, MX y TXT. No uses el cambio de sitio como motivo para borrar registros de correo, SPF, DKIM o DMARC.
3. Usa un subdominio de prueba. Prepara una copia de la aplicación en una carpeta privada de la cuenta, fuera de la raíz pública cuando la configuración lo permita. Utiliza datos de prueba y credenciales separadas; nunca apuntes una primera prueba a la base de producción.
4. Compila para producción. Instala dependencias desde el archivo de bloqueo y ejecuta el build de producción con una versión de Node compatible. El hosting puede tener límites que impidan compilar allí; confirma con el proveedor el flujo admitido antes de depender de una compilación local o de subir artefactos sueltos.
5. Configura el proceso con el gestor del hosting. Sigue el mecanismo de inicio y reinicio que soporte la cuenta. Define el puerto según el entorno, conserva los logs y guarda variables y secretos en el panel del proceso, no en el repositorio ni en archivos públicos. No uses el servidor de desarrollo para atender tráfico real.
6. Valida los flujos completos. Comprueba la página, los enlaces, errores 404, formularios, APIs, lectura y escritura de la base de pruebas, correo, tareas programadas y reinicio del proceso. Prueba desde fuera del cPanel con HTTPS; un mensaje de “aplicación iniciada” no demuestra que el dominio y todas sus rutas funcionen.
7. Comprueba límites del plan. Revisa consumo de memoria, CPU, disco, concurrencia y duración máxima de tareas. Confirma si el proceso se reinicia tras una actualización del servidor y qué ocurre si supera una cuota.

Haz el corte después de aprobar la prueba

Solo cuando la versión de prueba responda bien, prepara la ventana de cambio. Coordina el estado más reciente de la base, verifica certificado TLS y compara la zona DNS con el respaldo. Cambia únicamente los registros web que correspondan al nuevo destino. Conserva los registros MX y de autenticación del correo, y deja preparado el valor anterior para volver atrás si la nueva aplicación falla.

Tras el cambio, revisa el sitio desde una conexión externa, consulta los logs del proceso y observa las funciones principales. No declares la migración terminada hasta comprobar que las solicitudes llegan al servidor nuevo y que el servicio anterior puede restaurarse si aparece un problema.

Si el plan cPanel no ofrece Node.js con la versión y los recursos que requiere el proyecto, mantén el sitio actual mientras eliges un destino compatible. Para una web informativa estática, la decisión puede ser distinta; para formularios, asistentes, CRM o procesos automáticos, comprueba cada dependencia antes de reducir la aplicación a archivos.

Checklist de decisión

• El plan y el dominio tienen Node.js 20.9+ habilitado.
• El proveedor confirma gestor de procesos, archivo de inicio y reinicio.
• Los límites de recursos admiten build, ejecución y tareas requeridas.
• La prueba usa HTTPS, datos aislados y secretos guardados fuera del código.
• Formularios, APIs, correo, base de datos y cron pasan validación funcional.
• La zona DNS tiene respaldo y el plan de reversión está listo.

Si todavía comparas alternativas, revisa primero el servicio de diseño y desarrollo web y describe el dominio, el framework, las funciones del sitio y lo que el proveedor cPanel confirmó. Así se puede elegir una ruta de despliegue compatible antes de modificar la web pública.