Vercel Flags: comparte flags entre proyectos sin SDK keys

¿Qué cambió en Vercel Flags con las conexiones entre proyectos?

Vercel habilitó las conexiones entre proyectos (Project Connections) en Vercel Flags: ahora una aplicación puede evaluar los flags definidos en otro proyecto del mismo equipo sin copiar ni rotar una SDK key de servidor. El proyecto consumidor se autentica con la identidad de su propio despliegue, mediante un token de identidad OIDC (OpenID Connect, el estándar de autenticación entre servicios que ya usan las plataformas cloud).

Antes, compartir flags entre dos proyectos obligaba a copiar una server SDK key dentro de una variable de entorno y administrarla a mano: rotarla, cuidarla, evitar que se filtrara. Ahora el acceso se otorga y se revoca desde el dashboard.

La función está disponible en todos los planes. Para un equipo que mantiene varias aplicaciones —web pública, panel interno, documentación, microfrontends— el ahorro real no es escribir menos código: es dejar de tener credenciales de largo plazo replicadas en cada repositorio.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Cómo autentica un proyecto consumidor sin SDK keys?

El proyecto fuente es el dueño de los flags. El consumidor solo los lee y los evalúa, y lo hace con su propio token OIDC: no hay una credencial fija que rotar cada cierto tiempo.

Para desarrollo local, vercel env pull trae el token OIDC del proyecto a tu .env.local (Next.js lo carga automáticamente). El token expira, así que hay que volver a ejecutar el comando cuando caduque: un detalle operativo fácil de olvidar en el día a día de un equipo chico.

Los permisos tampoco son los que muchos esperan. Crear o eliminar una conexión requiere ser Member o Owner del equipo, o Project Admin del proyecto fuente. Crear la conexión además exige permiso para ver el proyecto consumidor; eliminarla, no. El rol Developer o Project Developer por sí solo no alcanza, y no hace falta ser Owner del equipo. En planes Enterprise, los roles de proyecto configurables solo pueden asignarse a Contributors del equipo.

¿Cómo se configura la conexión paso a paso?

Abre el proyecto fuente en el dashboard de Vercel y entra a Flags → Connections.
En la sección flags can be read by, elige New Connection y selecciona el proyecto consumidor. También puedes partir del consumidor, desde can read flags from.
Expande la conexión para copiar el fragmento del adapter con el ID del proyecto fuente.
Instala las dependencias en la app consumidora (flags y @flags-sdk/vercel).
Crea el adapter con el ID del proyecto fuente y define tu flag:

import { flag } from 'flags/next';
import { createVercelAdapter, vercelAdapter } from '@flags-sdk/vercel';

const sharedAdapter = createVercelAdapter({ projectId: 'prj_source' });

export const sharedCheckout = flag({
  key: 'new-checkout',
  defaultValue: false,
  adapter: sharedAdapter(),
});

export const localFeature = flag({
  key: 'local-feature',
  defaultValue: false,
  adapter: vercelAdapter(),
});

En el directorio del consumidor, corre vercel link y luego vercel env pull.

Si prefieres la terminal, la CLI de Vercel (versión 63.0.0 o superior) permite administrar todo: vercel flags connections add storefront --project checkout crea la conexión, vercel flags connections list --project checkout muestra qué proyectos pueden leer los flags de checkout, y vercel flags connections list --project storefront --role consumer lista de dónde lee storefront. Para revocar el acceso: vercel flags connections remove storefront --project checkout.

Las versiones mínimas son @flags-sdk/vercel 1.6.0 o superior, o @vercel/flags-core 1.11.0 o superior si usas la librería core directamente.

¿Qué gana tu equipo al centralizar los flags?

Revocación sin redeploy. Quitar la conexión corta el acceso al instante. No hay que volver a desplegar ninguna aplicación para que deje de evaluar los flags de otro proyecto.
Una sola fuente de verdad. Varios microfrontends pueden consumir los release flags de un mismo proyecto, y las reglas de segmentación se cambian en un único lugar.
Menos secretos circulando. Desaparecen las SDK keys copiadas proyecto por proyecto: el acceso vive en la identidad del despliegue.
Sin costo extra de plan. Las conexiones están disponibles en todos los planes, aunque las evaluaciones de flags y las lecturas de configuración siguen contando para el uso del proyecto fuente, igual que ocurre con las SDK keys.

El trade-off central conviene tenerlo claro: la conexión es de solo lectura y da acceso a todos los flags del proyecto fuente, en todos los entornos. No se puede limitar a un flag puntual ni a un entorno específico. Ganas simplicidad, pierdes granularidad.

El detalle que más problemas causa: entornos y transferencias

El entorno lo determina el despliegue consumidor, no una configuración manual. Un despliegue de producción evalúa flags de producción; uno de preview, de preview; uno de desarrollo, de desarrollo. Los entornos personalizados apuntan a preview.

Hay dos escenarios donde conviene planificar antes de conectar:

Transferir o borrar proyectos. Si mueves cualquiera de los dos proyectos a otro equipo, o lo eliminas, la conexión desaparece. Las conexiones no se convierten en SDK keys automáticamente. Si necesitas seguir leyendo flags entre equipos después de una transferencia, configura SDK Keys en cada proyecto consumidor y redespliega antes de mover nada.
Definiciones embebidas. El paso de build también descarga las definiciones de los proyectos conectados, así que crea la conexión antes de construir si quieres que entren en las definiciones de fallback del despliegue.

¿Qué significa esto para tu startup?

Si hoy compartes una SDK key de flags entre dos o más aplicaciones, este cambio elimina una credencial de largo plazo de tu infraestructura. Es trabajo de minutos que reduce superficie de ataque: una key filtrada en un repositorio o en un log deja de ser un riesgo permanente.

Tres acciones concretas para implementarlo bien:

Haz inventario. Lista qué proyectos evalúan los mismos flags. Si la misma key aparece en más de un archivo de entorno, tienes un candidato claro a conexión.
Define defaultValue en cada flag. La documentación de Vercel lo recomienda de forma explícita: si el token expira o alguien revoca la conexión, la aplicación debe seguir funcionando con un valor por defecto, no romperse en producción.
Elige un proyecto dueño y documenta el mapeo de entornos. Antes de conectar, decide qué proyecto es la fuente y deja por escrito qué pasa en preview y en entornos personalizados. Así evitas la sorpresa de evaluar flags de producción desde un despliegue de preview.

Para agencias y equipos que administran productos de varios clientes, el patrón también es útil: un proyecto central expone los flags y cada aplicación de cliente los lee sin recibir nunca la credencial. Y como la conexión se revoca sin redeploy, cerrar el acceso cuando termina un contrato es inmediato.

Conclusión

Vercel Flags cierra el último punto donde compartir flags obligaba a mover secretos a mano. El beneficio no es solo de conveniencia: es de higiene de credenciales. La contrapartida —acceso total y de solo lectura a todos los flags y entornos, más la dependencia entre proyectos ante una transferencia— se maneja con dos hábitos: definir defaultValue siempre y tener un plan claro de qué pasa si un proyecto cambia de equipo. Si tu equipo todavía copia SDK keys entre repositorios, esta es una de las migraciones más baratas que puedes hacer este trimestre.