¿Cómo desplegar Next.js 15 y Supabase sin mezclar variables?

Para desplegar un SaaS con Next.js 15 y Supabase en Vercel sin mezclar variables, clasifica cada valor por consumidor y entorno antes del primer deploy: público para el navegador, secreto para el servidor y separado entre desarrollo, preview y producción. Después prueba el flujo completo sobre la URL desplegada, no solo en local.

¿Cómo se clasifica cada variable antes de desplegar?

Cada variable se clasifica preguntando quién debe leerla: navegador, servidor o proveedor externo. Una clave de servicio de Supabase puede saltarse controles y nunca pertenece al bundle público; un secreto de webhook solo sirve al endpoint que verifica firmas; una URL pública de proyecto sí puede usarla el cliente junto con las políticas de RLS.

Documenta nombre, propietario, entorno y finalidad. Evita duplicar valores a mano sin saber de dónde salieron. El repositorio debe contener un ejemplo sin secretos, mientras los valores reales viven en la configuración de Vercel.

¿Cómo se separan desarrollo, preview y producción?

Los entornos se separan asignando a cada uno recursos y credenciales controlados, especialmente cuando una preview puede escribir datos o iniciar pagos. Como mínimo, evita que una rama de prueba comparta claves privilegiadas con producción sin una razón explícita.

Las previews por rama son útiles para revisar interfaz y recorridos, pero también cambian el origen de la petición. Decide qué callbacks admite Supabase, qué URL devuelve la pasarela y si los webhooks de prueba apuntan a un endpoint estable. Si estás empezando desde cero, el artículo sobre boilerplates de Next.js y Supabase explica qué trabajo repetitivo conviene resolver una sola vez.

¿Qué cambia en autenticación, RLS y webhooks al salir de local?

Al salir de local cambian los dominios permitidos, las redirecciones y la disponibilidad real de secretos, pero no debería cambiar el modelo de seguridad. Las páginas privadas verifican la sesión en servidor y los datos siguen protegidos por RLS; ocultar un botón no protege una tabla.

Prueba registro, login social, cierre de sesión y acceso directo a una ruta privada. La guía de autenticación con Supabase en Next.js detalla esas capas. Para pagos, confirma que el endpoint recibe el cuerpo en el formato esperado, tiene el secreto correcto y responde sin depender de una pestaña del comprador.

¿Qué checklist confirma que el SaaS está listo?

La checklist final confirma build limpio, variables presentes, callbacks correctos, RLS activa, auth funcional, pago de prueba, webhook verificado y páginas legales accesibles. Añade una prueba desde móvil y una navegación anónima para detectar supuestos creados por tu sesión local.

IndiePack está pensado para que este deploy sea una etapa repetible, no una improvisación: la misma base documentada acompaña el código desde la primera preview hasta producción.