Manejo seguro de variables de entorno en Next.js y Supabase
Buenas prácticas para estructurar tus secretos en entornos local, staging y producción en Vercel sin exponer credenciales críticas en tu repositorio.
- #supabase
- #security
- #next.js
- #env-variables
En el desarrollo de aplicaciones web modernas, la seguridad de las credenciales de acceso es un pilar fundamental. Al integrar Next.js con servicios backend como Supabase, manejas diferentes tipos de claves: la clave pública de la API (Anon Key) y la clave de servicio administrativa (Service Role Key). Subir accidentalmente estas claves a un repositorio público en GitHub es uno de los errores de seguridad más comunes y costosos que puede cometer un desarrollador. Configurar adecuadamente tus variables de entorno es la primera línea de defensa.
Variables públicas vs Variables privadas
Next.js utiliza un sistema de prefijos muy claro para gestionar el acceso a las variables de entorno. Cualquier variable que empiece con NEXT_PUBLIC_ (como NEXT_PUBLIC_SUPABASE_URL) estará disponible tanto en el servidor como en el navegador del cliente. Esto es necesario para inicializar el cliente de Supabase que se ejecuta en los componentes del navegador.
Por el contrario, las variables sin este prefijo (como SUPABASE_SERVICE_ROLE_KEY) son estrictamente privadas. El compilador de Next.js garantiza que estas variables nunca se inyecten en el bundle de JavaScript del cliente. Estas claves de administración tienen bypass de políticas de seguridad (RLS) en la base de datos, por lo que NUNCA debes exponerlas públicamente o usarlas en componentes de cliente.
Estructurando tus entornos
Para un flujo de trabajo profesional, debes usar archivos de configuración diferenciados en tu máquina local. Mantén un archivo .env.local para tus credenciales locales (este archivo debe estar incluido en tu .gitignore obligatoriamente) y jamás commitees valores de producción. En tu plataforma de despliegue (como Vercel), configura las variables de entorno directamente en el panel de control del proyecto, diferenciando los valores para entornos de vista previa (Staging) y de producción final.
Implementar este nivel de separación no solo protege los datos de tus clientes y de tus usuarios contra accesos no autorizados, sino que te permite iterar rápido probando cambios en bases de datos locales o de prueba sin riesgo de alterar el entorno de producción real por un error de configuración.
¿Construyendo algo?
Si esto te ha resonado, podemos hablar. Contactar →