Alojar React, Vue y webs estáticas conectadas a APIs externas

Sí puedes alojar un proyecto hecho con React, Vue u otro framework JavaScript cuando el resultado de la compilación sea una web estática. El hosting sirve los ficheros HTML, CSS, JavaScript e imágenes ya terminados; no necesita mantener Node.js en ejecución para mostrarlos.

Una aplicación moderna suele estar dividida en dos partes:

Frontend: se compila con Vite, Webpack, Rollup u otra herramienta y genera un directorio como dist, build u out. Puedes compilarlo en tu cuenta con Node.js y npm, incluso dentro de Deploy+, y publicar el resultado con normalidad.
Backend externo: la base de datos, la autenticación o el almacenamiento permanecen en Supabase, Firebase, Strapi Cloud, Sanity, Airtable o cualquier otro proveedor. El navegador del visitante se conecta a su API por HTTPS, por lo que ese servicio no se instala ni se ejecuta en el hosting.

El hosting solo necesita ser compatible con aquello que se ejecuta en él. Una API externa no requiere soporte especial por parte del alojamiento.

Dos formas de llamar a la API externa

En un frontend completamente estático, la comunicación sigue este recorrido:

Visitante → HTML, CSS y JS del hosting → API del proveedor

En este caso el navegador llama directamente al proveedor. Su API debe aceptar peticiones desde tu dominio mediante CORS y debes configurar allí los dominios permitidos y las URL de retorno de la autenticación.

También puedes interponer un backend PHP alojado en la cuenta:

Visitante → frontend del hosting → PHP del hosting → API del proveedor

PHP puede realizar conexiones salientes y llamar por HTTPS a cualquier API externa con normalidad, mediante cURL, Guzzle o el cliente HTTP de frameworks como Laravel. Esta arquitectura resulta útil cuando necesitas guardar una clave privada, validar o transformar los datos antes de enviarlos, o evitar que una operación sensible se ejecute desde el navegador. PHP sí interviene en estas peticiones, pero la API y sus datos continúan alojados en el proveedor externo.

Las restricciones CORS del navegador no se aplican a la comunicación entre PHP y el proveedor. La API seguirá exigiendo sus credenciales, permisos y límites de uso habituales.

Qué proyectos encajan y cuáles necesitan un VPS

Proyecto o función	Hosting compartido	Motivo
React, Vue, Svelte o Angular compilados como web estática	Sí	El servidor solo entrega los ficheros generados
Proyecto de Vite, Webpack o Rollup cuyo resultado sea HTML, CSS y JS	Sí	Node.js se usa durante la compilación, no al recibir visitas
Astro u otro generador configurado con salida estática	Sí	Todas las páginas se generan antes del despliegue
Next.js con `output: 'export'`	Sí	`next build` crea una exportación estática en `out`
Frontend que consulta Supabase, Firebase, Strapi Cloud, Sanity, Airtable u otra API	Sí	El servicio se ejecuta fuera del hosting
Frontend que consulta una API externa a través de PHP	Sí	PHP puede hacer peticiones HTTPS salientes
Express, Nest, Koa u otro servidor Node.js escuchando en un puerto	No	Necesita un proceso permanente
Next.js con SSR, Server Actions, rutas dinámicas de API o funciones de servidor	No	Necesita el runtime de Next.js atendiendo peticiones
WebSocket, worker, consumidor de colas o tarea Node.js permanente	No	Necesita un proceso continuo

Para los casos que necesitan un proceso permanente debes usar un VPS con acceso root. El nombre del framework no decide por sí solo la compatibilidad: lo importante es si el build termina en ficheros estáticos o si la aplicación exige ejecutar un servidor.

El caso de Next.js

Next.js puede funcionar de las dos formas y por eso suele generar dudas. Para producir una web estática, configura la exportación, por ejemplo en next.config.mjs:

const nextConfig = {
  output: 'export',
};

export default nextConfig;

Al ejecutar next build, Next.js crea el directorio out, que contiene los ficheros que debes publicar. La documentación de exportaciones estáticas de Next.js detalla qué funciones admite este modo.

Una exportación estática no puede resolver en cada visita lógica que dependa de un servidor de Next.js, como SSR, cookies leídas en el servidor, Server Actions o rutas de API dinámicas. Si el proyecto usa esas funciones, debes adaptarlas a una API externa o a endpoints PHP, o alojar la aplicación en un VPS.

Publicar el proyecto con Deploy+

Un frontend compilado es un caso ideal para Deploy+: cada despliegue clona el repositorio en una versión nueva, ejecuta el build allí y solo la hace pública cuando todos los comandos han terminado correctamente.

Al conectar el repositorio:

En el paso Proyecto, elige Frontend compilado. Deploy+ propone dist como raíz web y un script que ejecuta npm ci y npm run build.
Comprueba el directorio que genera tu proyecto. Conserva dist para la configuración habitual de Vite, pero cámbialo por build, out u otra ruta si tu herramienta utiliza un nombre diferente. Una exportación estática de Next.js usa out.
Revisa el script propuesto. Cada línea se ejecuta en una shell independiente, por lo que todas las líneas que usen npm, npx o node deben activar NVM en esa misma línea. El perfil ya viene preparado de esta forma.
En Automatización, activa Desplegar al hacer push si quieres que cada cambio de la rama elegida genere una versión nueva.

Deploy+ comprueba Node.js antes de ejecutar un script que lo necesite y lo instala automáticamente si todavía no está disponible en la cuenta. Si tu package.json exige una versión concreta, selecciónala antes del primer despliegue desde Hosting → tu servicio → Gestor de paquetes, como se explica en el manual de instalación de Node.js y npm.

Si npm ci indica que no existe un fichero de bloqueo, añade package-lock.json al repositorio o cambia conscientemente ese comando por npm install. Conservar el fichero de bloqueo permite instalar las mismas versiones de las dependencias en cada build.

El script se ejecuta antes de activar la release. Si la instalación de dependencias o el build fallan, la versión anterior continúa publicada y los visitantes no reciben una web a medio compilar. Si detectas un problema después de publicarla, abre el historial y usa Volver a esta versión sobre una release anterior. Cuando esa release aún está guardada, Deploy+ solo cambia el enlace simbólico y la vuelta tarda segundos; si ya se eliminó durante la limpieza de versiones antiguas, deberá reconstruirla desde el repositorio y tardará más.

La vuelta atrás cambia el código y los assets publicados, pero no deshace operaciones ya realizadas en la API externa ni restaura los datos o la configuración del proveedor.

El `.env` de Deploy+ y las claves del servicio externo

Deploy+ conserva el fichero .env en la carpeta compartida y lo enlaza en cada release antes de ejecutar el script. En un frontend estático, el empaquetador lee las variables durante el build: no existe un proceso de Node.js que vuelva a leer .env cuando llega una visita.

Todo valor incluido en el JavaScript compilado puede verlo un visitante desde su navegador. Cambiar el nombre de la variable o guardarla en un fichero .env no la convierte en secreta.

En el bundle solo debes incluir valores públicos, por ejemplo:

La URL de la API o el identificador del proyecto.
Una clave que el proveedor describa expresamente como pública, publicable o destinada al navegador.
Identificadores públicos de analítica o configuración.

No incluyas contraseñas, claves de administración, claves secretas, claves service_role, tokens privados ni credenciales de base de datos. Si una operación necesita uno de esos secretos, hazla desde PHP y conserva la credencial en el .env compartido o en otro fichero de configuración fuera de la raíz web. Cárgala en PHP mediante el sistema de configuración del framework o una librería para .env, sin enviarla al navegador ni escribirla en registros.

Vite incorpora al bundle las variables con prefijo VITE_, tal como advierte su documentación sobre variables de entorno. Next.js hace lo mismo con NEXT_PUBLIC_. Además, estos valores quedan fijados al compilar: si modificas uno, debes volver a ejecutar el build y desplegar el resultado.

No todos los proveedores llaman igual a sus credenciales ni ofrecen una clave apta para el navegador. Consulta siempre su documentación. Por ejemplo:

Supabase destina la clave publishable al navegador y reserva la secret para el servidor. Los nombres antiguos anon y service_role son sus equivalentes heredados. Su documentación de claves indica que la clave pública debe acompañarse de Row Level Security y permisos mínimos.
La configuración web y las claves de Firebase son públicas por diseño. Firebase protege los datos mediante Security Rules y App Check, no ocultando esa configuración.

Las claves públicas no sustituyen los controles de acceso. Activa en el proveedor las reglas por usuario, políticas de filas, permisos de almacenamiento, restricciones de uso y demás protecciones que correspondan.

Rutas internas de una SPA

Si tu aplicación es una SPA con un único index.html y gestiona las rutas en el navegador, una recarga directa de /panel podría devolver un error 404. En ese caso añade a su directorio público un fichero .htaccess que conserve los ficheros reales y envíe el resto de rutas a index.html:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.html [L]

Esta regla es para SPA con enrutado del lado del cliente. No la uses sin más en una exportación que ya genera un fichero HTML distinto para cada ruta.

Después de publicar, abre la web desde su dominio definitivo y prueba el acceso directo a una ruta interna, el inicio de sesión, las llamadas a la API y la subida de ficheros si existe.