Elige tu tipo de app y hosting para obtener el comando de build, la carpeta de salida y el archivo de rewrite que evita los 404 al recargar en Vercel, Netlify, Cloudflare y GitHub Pages.
Para desplegar una app de React, ejecuta el build de producción y entrega la carpeta de salida a un hosting: dist para Vite, out para un export estático de Next.js. Las aplicaciones de una sola página también necesitan un rewrite que envíe las rutas desconocidas a index.html; si no, recargar un enlace profundo devuelve 404. Una app completa de Next.js necesita un hosting que ejecute Node.js.
Salida del build según el tipo de app
La mayoría de los despliegues fallidos de React se reducen a tres cosas: la carpeta de salida equivocada, la falta de un rewrite para las rutas del lado del cliente o una función de Next.js que necesita servidor enviada a un hosting estático. Elige abajo tu tipo de app y tu hosting para ver la configuración y el archivo exactos de esa combinación, sacados de la documentación de cada hosting.
El router vive en el navegador, pero al recargar se pide al servidor un archivo como /about/index.html que no existe. Un rewrite que devuelve index.html para las rutas desconocidas permite que el router vuelva a tomar el control. Cada hosting tiene su propia sintaxis para esa regla.
No, si tu build no tiene un 404.html en el nivel superior. Según la documentación de Cloudflare, Pages trata entonces el proyecto como una app de una sola página y sirve el index raíz para cualquier ruta que no sea un archivo real.
Solo como export estático con output: 'export'. GitHub Pages sirve archivos y no puede ejecutar el servidor de Next.js, así que funciones como server actions, cookies, rewrites y renderizado bajo demanda no están disponibles ahí.
Un redirect envía al navegador a una URL nueva, lo que cambia la barra de direcciones. Un rewrite sirve otro archivo manteniendo la URL solicitada, que es lo que necesita una app de una sola página. Netlify marca un rewrite con el estado 200.
Configúralas en los ajustes del proyecto del hosting, no en un archivo .env incluido en el repositorio. Recuerda que las variables que llegan al navegador son públicas, así que guarda las claves que deben ser privadas en un servidor o en funciones serverless.
Dónde va la regla comodín (según la documentación de cada hosting, octubre de 2026)
La misma regla que el archivo _redirects de una línea. El estado 200 conserva la dirección que pidió el visitante.
Adaptado del workflow de la guía de despliegue de Vite (que fija cada action a un commit). Hace el build en cada push a main y publica dist. Activa GitHub Actions como origen en Settings, luego Pages.
Importa el repositorio; Vercel detecta Vite. Añade este archivo en la raíz del proyecto para que los enlaces profundos carguen la app.
Comando de build npm run build, directorio de publicación dist. Guarda esta línea como public/_redirects para que Vite la copie en dist.
Conecta el repositorio y elige el preset de Vite. No hace falta ninguna regla mientras dist no tenga un 404.html en el nivel superior, porque entonces Pages sirve el index raíz para las rutas desconocidas.
Configura base con el nombre de tu repositorio, haz el build con GitHub Actions y publica dist. GitHub Pages admite un 404.html personalizado pero no reglas de rewrite, así que una solución habitual es copiar index.html a 404.html después del build; esos enlaces profundos cargan entonces con estado 404.
Vercel compila Next.js directamente, así que aquí el export estático es opcional. Mantenlo solo si quieres los mismos archivos en todas partes.
Configura el directorio de publicación como out. Cada ruta ya tiene su propio archivo HTML, así que no hace falta un rewrite comodín.
Usa npm run build con el directorio de salida out. El export incluye un 404.html, así que Pages lo sirve para las rutas que faltan en lugar de la página de inicio.
El export estático es la única forma de ejecutar Next.js aquí. Si el sitio vive bajo la ruta de un repositorio, configura basePath para que coincida.
Importa el repositorio y despliega. Vercel es uno de los adaptadores verificados que aparecen en la documentación de despliegue de Next.js.
Netlify ejecuta Next.js mediante su propia integración, que la documentación de Next.js todavía no incluye como adaptador verificado. Revisa su documentación por si faltan funciones.
Cloudflare ejecuta Next.js en Workers mediante su propia integración, que tampoco es todavía un adaptador verificado. Sigue su guía del framework en lugar del flujo estático de Pages.
No es posible. GitHub Pages solo sirve archivos y no puede ejecutar next start. Pasa a un export estático o elige un hosting que ejecute Node.js.
Vite + React
Export estático de Next.js
App completa de Next.js
Vercel
Netlify
Cloudflare Pages
GitHub Pages
¿Qué has creado?
¿Dónde se va a ejecutar?
Todas las combinaciones de app y hosting
Copiar
Empieza gratis · Sin tarjeta de crédito