Has llegado al último módulo del curso. Y lo que vas a aprender aquí no es teoría nueva: es cómo usar todo lo anterior en el orden correcto.

Porque saber qué es Supabase y qué es Vercel está bien. Pero lo que de verdad cambia cómo trabajas es entender cómo se mueven las piezas juntas cuando quieres hacer algo real.

Dos entornos, una app

Cuando trabajas con Supabase y Vercel, tu app vive en dos sitios a la vez.

El primero es tu ordenador. Aquí pruebas los cambios antes de que nadie los vea. Se llama entorno local o development. Puedes romper cosas sin consecuencias.

El segundo es Vercel. Aquí está la versión que usan tus invitados. Se llama entorno de producción o production. Lo que está aquí es lo que el mundo ve.

La clave es que un cambio en tu ordenador no llega a producción solo. Tú decides cuándo subirlo.

Qué tipo de cambio es cada cosa

No todos los cambios funcionan igual. Hay dos tipos y es importante distinguirlos:

Cambios en Supabase — la base de datos, las políticas RLS, los códigos de acceso y las carpetas de Storage. Estos cambios son instantáneos y globales. En cuanto los haces en el panel de Supabase, tanto tu entorno local como el de producción los ven. No necesitas hacer deploy.

Cambios en el código — lo que está en tu proyecto Next.js: cómo se ve la pantalla, qué botones hay, qué lógica sigue la app. Estos cambios solo llegan a producción cuando haces git push y Vercel los despliega.

En la práctica: si cambias una política de RLS en Supabase, el cambio ocurre en el momento. Si cambias el color de un botón en tu código, tienes que subirlo para que se vea en producción.

Códigos de acceso, no cuentas de usuario

En este curso usamos códigos de acceso por familia en lugar de cuentas de usuario. Es una forma más sencilla de proteger el álbum sin pedir a cada invitado que se registre, confirme su email o recuerde una contraseña.

Supabase también permite crear sistemas completos de autenticación con email, contraseña o proveedores externos como Google. Eso se llama Supabase Auth. Es muy útil en proyectos más avanzados, pero para MiraMiEvento queremos mantener el flujo simple: una persona entra, escribe su código y ve las fotos que le corresponden.

El flujo real paso a paso

Nota sobre la parte técnica

Los comandos que ves en este módulo — git, npm, configurar variables de entorno — los ejecuta un agente de código como Claude Code, Codex u otro similar. Tú describes lo que quieres cambiar; el agente lo hace. No necesitas aprender la terminal para usar este flujo.

Imagina que quieres añadir un mensaje de bienvenida personalizado en MiraMiEvento. Algo que muestre el nombre de la familia cuando entran con su código. Así sería el proceso completo:

  1. Haces el cambio en tu ordenador. Abres el proyecto en tu editor, modificas el componente que muestra la pantalla de bienvenida y añades el mensaje.
  2. Lo pruebas en local. Arrancas el proyecto con npm run dev y abres el navegador en localhost:3000. Ves el cambio, compruebas que funciona y revisas que no hay errores en la consola.
  3. Lo subes a GitHub. Cuando el resultado está bien, ejecutas:
git add .
git commit -m "añadir mensaje de bienvenida personalizado"
git push
  1. Vercel despliega automáticamente. En cuanto detecta el push, empieza el proceso de build. En unos minutos la nueva versión está en producción.
  2. Compruebas el resultado. Abres la URL de tu app en Vercel y ves el cambio publicado.

Eso es todo. Este ciclo — cambiar, probar, subir, verificar — es exactamente lo que hace cualquier persona que desarrolla una app, independientemente de su nivel.

Qué pasa si algo falla en producción

Ocurre. No siempre, pero ocurre.

Si el build falla, Vercel no despliega nada. La versión anterior sigue activa y tus invitados no notan nada. Tú recibes un aviso con el error y puedes revisarlo en el panel de Vercel.

Si el build funciona pero la app se rompe en producción con un error que no veías en local, lo más habitual es que falte alguna variable de entorno. Revisa que todas las variables de tu archivo .env.local estén también en Vercel → Settings → Environment Variables.

Cuándo tocar Supabase y cuándo tocar el código

Esta es la pregunta práctica que te harás más veces. Una guía rápida:

Quiero…Donde se haceNecesita deploy?
Anadir una nueva carpeta de fotosSupabase StorageNo
Cambiar quien puede ver queSupabase RLS o codigos de accesoNo
Anadir un nuevo campo a la base de datosSupabase Table EditorNo, salvo que el codigo tenga que usarlo
Cambiar el diseno de una pantallaCodigo Next.jsSi
Anadir una nueva paginaCodigo Next.jsSi
Corregir un texto en la interfazCodigo Next.jsSi

Lo que has aprendido en este curso

Empezaste sin saber qué era una base de datos. Ahora sabes:

  • Qué es Supabase y para qué sirve cada una de sus partes
  • Cómo se guardan datos en tablas y archivos en Storage
  • Qué es RLS y por qué protege tu app aunque alguien tenga la URL
  • Cómo funcionan los códigos de acceso por familia
  • Cómo funcionan las URLs firmadas y por qué caducan
  • Qué es Vercel y cómo pone tu app en internet
  • Qué son las variables de entorno y por qué nunca van escritas directamente en el código
  • Cómo funciona el flujo completo de trabajo

Eso no es teoría. Es la base real sobre la que se construyen aplicaciones como MiraMiEvento, y también muchas de las apps que usas cada día.

El siguiente paso

Ahora que entiendes cómo funciona el sistema, el siguiente paso es construir. No tiene que ser perfecto. Puede ser pequeño.

Una app para guardar fotos de un viaje. Un álbum para una boda. Una galería privada para tu equipo.

Las piezas ya las conoces. Ahora es cuestión de usarlas.


Fuentes

  • Deploying to Vercel | Vercel Docs — explica el ciclo completo de despliegue: cómo Vercel detecta un push en GitHub, realiza el build y publica la nueva versión automáticamente.
  • Instant Rollback | Vercel Docs — documenta cómo Vercel mantiene la versión anterior activa si el build falla, y cómo se puede revertir un despliegue instantáneamente.
  • Row Level Security | Supabase Docs — confirma que los cambios en políticas RLS de Supabase son instantáneos y globales, sin necesidad de hacer deploy del código.