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 peticiones HTTPS salientes a APIs externas, mediante cURL, Guzzle o el cliente HTTP de frameworks como Laravel. La API debe ser accesible y permitir el origen de red, las credenciales y la operación; sus restricciones o las del servidor pueden limitar una conexión concreta. 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 otro entorno

Para los casos que necesitan un proceso permanente utiliza un entorno que soporte y gestione ese runtime, como una plataforma de aplicaciones o un VPS. No siempre necesitas acceso root: depende del servicio elegido. 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 entorno que admita su runtime de servidor.

Publicar el proyecto con Deploy+

Puedes publicar un frontend compilado con 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:

1. 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.
2. 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.
3. 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.
4. 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 falta o no coincide el archivo de bloqueo, prepáralo en desarrollo, prueba las dependencias y guarda package-lock.json junto a package.json antes de desplegar. 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]

Incluye el .htaccess en el directorio que la herramienta copia al build; no basta con dejarlo en una carpeta del repositorio que no se publica. La regla debe aplicarse solo al frontend: si compartes la raíz con endpoints PHP o rutas de API, exclúyelos expresamente para no devolverles HTML.

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.

CORS no autentica usuarios ni protege por sí solo la API frente a otros clientes. Si añades un intermediario PHP, valida la sesión y los permisos y limita destinos y operaciones: no crees un proxy abierto que acepte cualquier URL del visitante. Configura también tiempos de espera y revisa el resultado antes de repetir operaciones con efectos.