Sí, puedes publicar un sitio Astro en un hosting compartido sin instalar Node.js en el servidor, siempre que generes el sitio como archivos estáticos. Compilas en tu equipo, subes el contenido de dist/ y el servidor web entrega esos archivos. Node.js participa en la compilación; no hace falta para servir HTML, CSS, JavaScript e imágenes ya generados.

Probé este flujo con una demostración mínima en BanaHosting, cPanel y LiteSpeed el 28 de octubre de 2026. El proyecto se compiló con Astro 7.3.1, Node.js v24.20.0 y npm 11.19.0, y se publicó en un subdominio de prueba. Los pasos de cPanel y los resultados de servidor que siguen describen esa cuenta concreta: otros planes y proveedores pueden comportarse de otra manera.

Cuándo sirve este método

Este procedimiento es adecuado para un proyecto que se genera como sitio estático y no necesita ejecutar Astro en cada petición. No es una solución para cualquier aplicación Astro: si dependes de SSR, middleware o funciones de servidor en tiempo de petición, necesitas un adaptador y un entorno de ejecución compatibles. En ese caso, copiar dist/ a un hosting estático no sustituye al servidor requerido.

Requisitos

  • Un proyecto Astro configurado para generar salida estática.
  • Node.js, npm y las dependencias del proyecto en el equipo donde compilarás.
  • Una cuenta de cPanel con acceso a File Manager y un dominio o subdominio cuyo document root puedas identificar.
  • Espacio para los archivos generados y un servidor web que pueda servirlos.
  • Para probar HTTPS, un certificado válido para el nombre de dominio.

En la demostración usé un proyecto separado del sitio Tecnéofito: portada, página /acerca/, archivo estático prueba.txt y una página 404.astro.

Compila el sitio en local

Desde la carpeta del proyecto, ejecuta el script de build definido por ese proyecto. En la demostración:

npm run build

Astro generó una salida estática en dist/. Antes de subir nada, comprueba el contenido:

dist/
├── index.html
├── acerca/
│   └── index.html
├── prueba.txt
└── 404.html

Terminal con versiones de Node.js, npm y Astro, archivos generados, contenido del ZIP y prueba de integridad.

Esta estructura es la de la demo, no una lista universal. Un proyecto real puede generar muchos más HTML y recursos. Revisa tu propio dist/ y confirma que contiene las páginas, archivos y assets que el sitio necesita. En Tecnéofito, por ejemplo, el script completo también genera el índice de búsqueda Pagefind; no era parte de esta demostración mínima.

Empaqueta el contenido de dist/

El ZIP debe contener directamente los archivos del sitio, no una carpeta dist/ que los envuelva. Desde la raíz del proyecto, puedes crearlo así:

cd dist
zip -r ../sitio.zip .
unzip -l ../sitio.zip

La salida real de la demostración se inspeccionó y contenía index.html, acerca/index.html, prueba.txt y 404.html en la raíz del archivo ZIP, sin prefijo dist/. Revisa la lista antes de transferirla.

Crea un subdominio con raíz independiente

Para probar sin mezclar los archivos con otro sitio, creé astro-demo.tecneofito.com en cPanel con un document root propio, separado de public_html. En el formulario desmarqué la opción para compartir el document root con el dominio principal.

Antes de crear un subdominio en otra cuenta, confirma la ruta que cPanel propone y que no comparte por accidente la raíz de un sitio existente. El nombre y la ubicación de las opciones pueden variar según la interfaz disponible.

Sube y extrae el ZIP con File Manager

Abre en File Manager el document root asignado al subdominio. Sube el ZIP y utiliza la opción Extract en esa misma carpeta. En el diálogo, confirma el destino antes de extraer: index.html debe quedar directamente en la raíz del sitio, y la página interna dentro de acerca/.

Después de extraer, comprueba el listado y la ubicación de los archivos. No basta con que el ZIP aparezca en File Manager.

Configura HTTPS, el dominio canónico y la página 404

En la cuenta de la demostración, AutoSSL mostró certificados validados para el subdominio y su variante www. Comprueba el estado de SSL para tus propios nombres antes de probarlos con HTTPS; la emisión y los tiempos dependen de la cuenta y de su configuración.

Para LiteSpeed/cPanel se probó esta configuración en .htaccess:

ErrorDocument 404 /404.html

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^astro-demo\.tecneofito\.com$ [NC]
RewriteRule ^ https://astro-demo.tecneofito.com%{REQUEST_URI} [R=301,L]

ErrorDocument hace que el servidor use el 404.html generado por Astro para mostrar la página de error. Las condiciones de reescritura fuerzan HTTPS y normalizan el host hacia la variante sin www. La regla conserva la ruta solicitada mediante %{REQUEST_URI}; al no descartar la query string, los parámetros se mantienen.

Antes de usarla, sustituye astro-demo.tecneofito.com por el dominio propio en la condición y en el destino. Esta configuración se probó en la cuenta de demostración con LiteSpeed y cPanel; la forma de detectar HTTPS y el soporte de directivas pueden variar en otros servidores o detrás de otros proxies. Verifica el resultado en tu hosting para evitar bucles.

Comprueba páginas y recursos

En navegador, abre la portada, la página interna y el recurso estático:

Portada publicada con enlaces a la página interna, el recurso y la ruta de prueba 404.

Página interna /acerca/ servida por el sitio estático.

La URL del recurso estático también se comprobó mediante terminal.

Para revisar las respuestas del servidor, prueba las rutas con curl:

curl -sSI https://astro-demo.tecneofito.com/
curl -sSI https://astro-demo.tecneofito.com/acerca/
curl -sSI https://astro-demo.tecneofito.com/prueba.txt
curl -sSI https://astro-demo.tecneofito.com/ruta-inexistente/
curl -sSIL 'http://www.astro-demo.tecneofito.com/?prueba=1' --max-redirs 5

En la demostración se verificaron estos resultados: / devolvió 200, /acerca/ 200, /prueba.txt 200 y una ruta inexistente 404. Las variantes HTTP y www respondieron con 301 hacia el dominio canónico; también se verificó la conservación de parámetros de consulta. La captura de terminal muestra respuestas de rutas y redirecciones; las capturas del navegador muestran contenido visual, no prueban por sí solas el status HTTP.

Terminal con respuestas HTTP de páginas, recursos, rutas inexistentes y redirecciones del subdominio de prueba.

Configura la página 404

Astro generó 404.html, pero LiteSpeed mostró inicialmente su página de error predeterminada. En la prueba se configuró ErrorDocument 404 /404.html. Luego la URL inexistente mostró la página 404 de Astro y conservó el código HTTP 404. Comprueba ambos: una página que dice “404” puede estar servida por error con código 200.

Página 404 personalizada generada por Astro. La imagen muestra el contenido, no el status HTTP.

Errores frecuentes

  • Subir dist/ como una carpeta dentro del document root: extrae su contenido directamente en el document root.
  • Crear el ZIP desde el nivel equivocado: inspecciona el archivo y confirma que no empiece con dist/.
  • Compartir la raíz del dominio principal: verifica la casilla y el document root antes de crear el subdominio.
  • Probar solo la portada: comprueba también rutas internas y recursos.
  • Confundir página 404 visual con status 404: revisa el código HTTP con curl.
  • Forzar HTTPS antes de que SSL esté listo: confirma primero el certificado para el subdominio y www si usas ambos.
  • Intentar alojar SSR como archivos estáticos: revisa el modo de renderizado y los requisitos del adaptador.

Conclusión

Para un Astro estático, Node.js puede quedarse en local: compilas, empaquetas el contenido de dist/ y transfieres los archivos con cPanel File Manager. En la demo de BanaHosting el flujo funcionó para páginas estáticas, recursos, HTTPS y una 404 personalizada. Esa experiencia no demuestra que cualquier proyecto Astro o cualquier hosting compartido admita SSR o se comporte igual.