Saltar al contenido
← Volver al blog
infraestructuraapps

De la vista previa a producción: dominio, variables y respaldos

Cómo publicar en serio tu app hecha con vibe coding: hosting en Vercel, Netlify o Render, dominio propio y DNS, variables de entorno, respaldos y alertas de caída.

Por Equipo Devonauts5 min de lectura
Read in English →
Un hombre revisa una app en su celular en el escritorio

En la vista previa de Lovable, Bolt o Replit todo se ve perfecto. Pero compartir ese enlace con clientes reales es otra cosa: necesitas un dominio propio, que los datos de prueba no se mezclen con los reales, que haya copia de seguridad y que alguien se entere si la app se cae a las tres de la mañana.

Esta guía recorre ese paso, de "funciona en mi pantalla" a "funciona para cualquiera", sin dar por hecho que eres desarrollador.

1. Elige dónde va a vivir tu app

Muchas herramientas de vibe coding tienen su propio botón de publicar, y para empezar puede ser suficiente. Si quieres más control, o tu proyecto ya vive en GitHub, las opciones más comunes son:

  • Vercel: muy usado para proyectos con Next.js y React. Cada cambio en GitHub genera un despliegue nuevo.
  • Netlify: parecido, muy cómodo para sitios y apps de una sola página (React con Vite).
  • Render: útil cuando además necesitas un servidor que esté siempre encendido, tareas programadas o un backend propio.
  • Cloudflare Pages: otra opción sólida para sitios estáticos y apps de frontend.

Para la mayoría de apps generadas con IA (frontend en React y base de datos en Supabase o Firebase), cualquiera de estas opciones funciona bien. Lo importante es que el despliegue salga de tu repositorio, para que siempre sepas qué versión está publicada.

Un error típico: al publicar una app de una sola página, si entras directo a una ruta como /panel o recargas ahí, aparece un 404. Se arregla con una regla que envíe todas las rutas a index.html. En Netlify se hace con un archivo _redirects que contenga /* /index.html 200; en Vercel, con una regla rewrites en vercel.json.

2. Conecta tu dominio propio

  1. Compra el dominio en un registrador (o usa uno que ya tengas).
  2. En tu hosting, agrega el dominio al proyecto. Te va a mostrar exactamente qué registros DNS crear.
  3. En el panel DNS de tu dominio, crea esos registros tal como te los indican. Lo habitual es un registro A o ALIAS para el dominio raíz (tuapp.com) y un CNAME para www.
  4. Espera la propagación. Suele tardar minutos, aunque a veces lleva horas.
  5. Verifica que el certificado HTTPS se haya emitido (el candado en el navegador). Vercel, Netlify y Render lo hacen solos cuando el DNS está bien.

Decide cuál será la dirección principal (tuapp.com o www.tuapp.com) y redirige la otra hacia ella.

Si usas el correo con ese dominio, ten cuidado de no borrar los registros MX ni los TXT del correo al tocar el DNS.

3. Variables de entorno por entorno

Las variables de entorno guardan la configuración que cambia según dónde corre la app: la URL de tu proyecto de Supabase, claves públicas, la URL del sitio, etc.

  • Separa pruebas y producción. Lo ideal es tener un proyecto de base de datos para pruebas y otro para producción, para que un experimento no borre datos reales.
  • Cárgalas en el panel del hosting. Vercel, por ejemplo, permite valores distintos para Production, Preview y Development.
  • Vuelve a desplegar después de cambiarlas. En apps con Vite o Next.js, las variables públicas se incrustan al compilar: cambiar el valor en el panel no afecta a lo que ya está publicado hasta que generas un despliegue nuevo.
  • Nada secreto en variables públicas. Las que empiezan por VITE_ o NEXT_PUBLIC_ llegan al navegador. Las claves secretas van solo en el servidor.

Y un clásico al cambiar de dominio: el login deja de funcionar o te redirige a localhost. En Supabase, actualiza la Site URL y agrega tu dominio en Redirect URLs dentro de la configuración de Auth. Si usas inicio de sesión con Google u otro proveedor, revisa también allí las URL autorizadas.

4. Respaldos de la base de datos

Tu código está en GitHub; tus datos, no. Antes de tener usuarios reales:

  1. Revisa qué respaldos automáticos incluye tu plan y cuántos días se guardan.
  2. Programa una copia propia y periódica (por ejemplo con supabase db dump o pg_dump) y guárdala fuera del proveedor.
  3. Respalda también los archivos subidos por usuarios: en muchos servicios, el Storage no va dentro del respaldo de la base de datos.
  4. Prueba una restauración completa en un proyecto aparte. Así sabes cuánto tarda y que de verdad funciona.
  5. Antes de cualquier cambio grande en la base de datos (sobre todo si lo hace la IA), saca una copia manual.

5. Monitoreo y alertas

No deberías enterarte de que tu app está caída por un cliente molesto.

  • Monitor de disponibilidad: servicios como UptimeRobot o Better Stack visitan tu sitio cada pocos minutos y te avisan por correo o mensaje si no responde.
  • Registro de errores: herramientas como Sentry capturan los errores que ven tus usuarios en el navegador, con el detalle técnico para arreglarlos.
  • Alertas de uso y gasto: activa avisos en tu base de datos, tu hosting y tus proveedores de IA para enterarte antes de llegar a un límite.

6. Correos que sí llegan

Si tu app envía correos de confirmación o de recuperación de contraseña, revisa que lleguen a la bandeja de entrada y no a spam. El servicio de correo incluido en Supabase tiene límites bajos y está pensado para pruebas; para producción se recomienda configurar un SMTP propio (con un proveedor de correo transaccional) y autenticar tu dominio con SPF, DKIM y DMARC.

7. Antes de compartir el enlace

Repasa esta lista en una ventana de incógnito:

  1. La app carga en tu dominio, con HTTPS, y www redirige bien.
  2. Recargar cualquier página interna no da 404.
  3. Puedes registrarte con un correo nuevo, confirmar y entrar.
  4. Recuperar la contraseña funciona y el enlace apunta a tu dominio.
  5. Se ve bien en el celular.
  6. No quedan datos de prueba a la vista ni textos de ejemplo.
  7. Título, ícono y vista previa al compartir en redes están configurados.
  8. Tienes respaldo reciente y el monitor de disponibilidad está activo.
  9. Pasaste la checklist de seguridad antes de lanzar.

¿Te ayudamos a salir a producción?

El dominio, el DNS, las variables y los respaldos son justo la parte en la que muchas apps hechas con IA se quedan atascadas. En Devonauts la recorremos contigo: dejamos tu app publicada, respaldada y vigilada, y te explicamos cada pieza para que puedas seguir construyendo. Mira cómo funciona el rescate de apps hechas con IA o cuéntanos en qué punto estás.

¿Tu app sigue trabada?

Pasa el chequeo gratis con la URL de tu app, o pide la Auditoría de rescate de $299: un ingeniero senior revisa el código y te envía un informe escrito en 2 días hábiles.