Conectar tu frontend a datos de producción es el paso que transforma una demo local en una aplicación real, con usuarios, proyectos persistentes y reglas de seguridad. Si trabajas con Supabase y Devin, aquí verás cómo separar tu entorno local del de producción sin arriesgar información real. Esto le sirve a cualquier desarrollador que quiera un flujo profesional.
Por qué separar datos de desarrollo y producción
Hasta ahora, ShipBlog leía la información localmente. Tener datos de prueba mientras desarrollas nuevas funcionalidades o corriges errores es cómodo, pero necesitas datos de producción para que la aplicación se conecte a ellos cuando esté desplegada.
La idea es simple: puedes construir y romper cosas en local sin tocar la información real de tus usuarios. Y aquí viene lo interesante, esta práctica es común en entornos profesionales, donde conviven varios entornos para desarrollo, testing y producción [00:38].
¿Por qué usar entornos separados en desarrollo? Porque te permiten desarrollar y probar localmente sin afectar los datos reales de producción. Así puedes experimentar sin miedo a dañar información de usuarios.
Cómo conectar el frontend a producción con Devin
En la clase anterior usamos el Devin CLI para conectarnos vía MCP y crear los datos. Quedó pendiente conectar esa información. Ahora le indicamos a Devin que necesitamos conectar el frontend a producción [00:52].
Devin usa los mismos datos del MCP para encontrar los dos valores que necesita:
La URL de producción que se obtiene desde Supabase.
La publishable key, la clave publicable que reemplaza directamente en el archivo de variables de entorno.
Un punto clave sobre las variables de entorno: mantén los permisos bastante restringidos para saber exactamente qué se agrega ahí [01:26]. En este caso Devin tiene acceso, pero siempre pregunta antes de añadir o modificar algo directamente en las variables de entorno.
Qué preguntas hace Devin antes de tocar tus variables
Devin no actúa a ciegas. Va preguntando cómo quieres manejar cada situación:
Cómo manejar el entorno local frente a producción [01:38].
Si debe cambiar el archivo .local a producción para conectar directo a la base de datos de producción.
Si debe configurar el auth, el site URL y las redirect URLs del proyecto remoto [02:15].
Con esas respuestas, mantiene perfiles separados: un archivo de variables para producción y otro para local. Además deja las variables documentadas para que las configures en Vercel o cualquier host al desplegar [01:55].
¿Qué es una publishable key en Supabase? Es una clave publicable que tu frontend usa para conectarse a la base de datos. Se obtiene desde Supabase y se coloca en tu archivo de variables de entorno.
Cómo crear un comando para elegir el origen de los datos
Normalmente ejecutas npm run dev y ese comando levanta solo el servidor del frontend, usando el archivo de variables de entorno local [03:14].
Pero también pedimos un comando adicional para decidir manualmente desde dónde leer los datos. El resultado es este:
bash
npm run dev:prod
En lugar de usar las variables locales, este comando usa las variables de entorno de producción, que contienen las credenciales de acceso a los datos reales [03:36]. Tras las preguntas, Devin genera el archivo .env.prod junto al .env.local que ya existía [02:39].
¿Para qué sirve un archivo .env.prod? Guarda las variables de entorno de producción, como la URL y la clave de acceso a la base de datos real. Así separas las credenciales de producción de las de tu entorno local.
Qué pasa al ejecutar el frontend en producción
Abrimos una nueva sesión de terminal, distinta a la de Devin, y ejecutamos npm run dev:prod. Esto levanta el servidor del frontend apuntando directo al entorno de producción [03:52].
El frontend queda disponible en el puerto 3001 y nos lleva a la página de login. Aquí ojo con un detalle importante: al ingresar tu correo y dar en enviar, el sistema manda un email real [04:12]. No uses un correo falso, porque ya estás conectado a datos de producción.
Recibirás un magic link que, al hacer clic, te redirige de vuelta. El enlace sigue siendo localhost 3001 porque ese es tu frontend, pero los datos ya son de producción.
La prueba está en los números: aparecen los 10 registros que vimos en Supabase, cada uno con sus precios [04:37]. Tus datos locales solo tienen un proyecto con un único registro. La diferencia deja claro que la conexión funciona.
Con esto, ShipBlog ya tiene un backend real en dos entornos distintos y puedes desarrollar en local sin afectar datos reales. ¿Te animas a probar tu propio comando dev:prod y contarme cómo te fue?
