⏱️ Lectura: 14 min
Unleash permite apagar o encender una función en producción sin tocar el código ni esperar un nuevo despliegue, y es, según su propio repositorio, la plataforma open source de feature flags con más adopción en GitHub.
📑 En este artículo
- TL;DR
- ¿Qué son los feature flags?
- Por qué importan los feature flags
- Cómo funciona Unleash por dentro
- Ejemplos prácticos con SDKs de Unleash
- Cómo empezar con Unleash en local
- Casos de uso reales de los flags de features
- Errores comunes y buenas prácticas
- Comparativa: Unleash frente a otras formas de gestionar flags de features
- Profundizando: estrategias de activación avanzadas
- Preguntas frecuentes
- Referencias
El proyecto ofrece 15 SDKs oficiales y más de 15 mantenidos por la comunidad, lo que cubre casi cualquier lenguaje de backend o frontend. Para un equipo que despliega varias veces al día, separar el release del código de la activación de la función es la diferencia entre un bug que llega a todos los usuarios de golpe y uno que solo alcanza al 1%.
TL;DR
- Unleash separa el despliegue de código de la activación de una función mediante un flag evaluado en tiempo de ejecución.
- Una instalación local completa corre con
docker compose up -dy queda lista enlocalhost:4242. - Las estrategias de activación, como porcentaje, lista de usuarios o variante, decide quién ve la función sin tocar el código del cliente.
- Más de 30 SDKs oficiales cubren Java, Node.js, Python, Go, .NET y más, con la misma llamada
isEnabled()en cada uno. - Equipos con necesidades de auditoría ganan control de acceso por rol, change requests y SSO en las ediciones Enterprise.
¿Qué son los feature flags?
Los feature flags son interruptores de configuración que activan o desactivan una función en tiempo de ejecución, sin modificar ni redeployar el código fuente. Permiten lanzar una función a un porcentaje de usuarios y revertirla al instante si falla, sin depender de un rollback completo.
La analogía más simple es un interruptor de luz con varios circuitos: apagás uno sin cortar la electricidad de toda la casa. En software pasa algo parecido. El código de la función nueva ya está en producción, pero el flag decide si se ejecuta para un usuario en particular. Un feature flag no es solo un booleano guardado en una base de datos; es el punto donde el negocio decide quién ve qué, sin esperar al próximo ciclo de despliegue.
No todo interruptor de configuración es un feature flag. Una variable de entorno que fija el puerto del servidor no cambia en caliente ni depende de quién hace la petición. Un feature flag sí, y además necesita una interfaz donde un equipo de producto pueda prenderlo o apagarlo sin pedirle un deploy a nadie. Eso es justamente lo que resuelve Unleash: un servidor central con API y panel de administración, más SDKs que evalúan el flag dentro de cada aplicación cliente.
Por qué importan los feature flags
El motivo principal es separar dos eventos que durante décadas fueron el mismo: desplegar código y activarlo para los usuarios. Cuando ambos pasos están unidos, cualquier bug en una función nueva se nota en cuanto el deploy termina, y revertirlo implica otro deploy completo. Con los flags de features, el código puede vivir en producción apagado durante días antes de que alguien lo vea.
Esto habilita el desarrollo sobre una sola rama principal, incluso con funciones a medio terminar, porque el flag las mantiene ocultas hasta que están listas. También habilita el interruptor de emergencia: si una función nueva degrada el servicio, apagarla toma el tiempo de un clic en el panel, no el tiempo de un rollback de infraestructura.
El tercer motivo es la segmentación. Una estrategia de activación puede mostrar la función solo a usuarios internos, a una lista de clientes en beta o a un porcentaje creciente del tráfico. Eso convierte cada lanzamiento en un experimento controlado en lugar de una apuesta de todo o nada para el total de usuarios.
Cómo funciona Unleash por dentro
La arquitectura tiene tres piezas: una API central con su base de datos, un panel de administración web y los SDKs que corren dentro de cada aplicación cliente. El SDK no consulta la API en cada request: descarga la configuración completa de flags al iniciar y la refresca en segundo plano cada pocos segundos, así que evaluar un flag es una operación en memoria, no una llamada de red por usuario.
flowchart TD
A["App cliente"] --> B["SDK de Unleash"]
B --> C["Unleash API"]
C --> D[("Base de datos")]
C --> E["Admin UI"]
subgraph Servidor
C
D
E
endEsa separación es la razón por la que evaluar un flag toma microsegundos: la decisión de si está activo para ese usuario ya vive en la memoria del proceso. El costo lo paga el servidor de Unleash, que mantiene sincronizados a todos los SDKs conectados; en Unleash Open Source esa sincronización corre sobre una única base de datos Postgres.
Cada flag pertenece a un proyecto y vive en uno o más entornos (development, staging, production), así que se puede activar una función en staging sin que production la vea. Dentro de cada entorno, una o varias estrategias deciden el «quién»: todos los usuarios, un porcentaje fijo, una lista de IDs concretos o una combinación de constraints como país o versión de la app.
Hay además una diferencia de confianza entre los dos tipos de SDK. Un SDK de backend corre en un servidor que nadie más controla, así que su token puede ver la configuración completa de todos los flags. Un SDK de frontend corre en el navegador del usuario, donde cualquiera puede leer el código fuente de la página, por eso usa otra URL (/api/frontend/) y otro token, pensado para quedar expuesto sin filtrar la configuración de flags que no le corresponden a ese cliente.
sequenceDiagram
participant App as Aplicacion
participant SDK as SDK Unleash
participant API as Unleash API
App->>SDK: isEnabled("nuevo-checkout")
SDK->>API: sincroniza configuracion cada pocos segundos
API-->>SDK: lista de flags y estrategias
SDK-->>App: true o false segun la estrategia
Note over App,SDK: la evaluacion es local, sin llamada por requestEjemplos prácticos con SDKs de Unleash
El ejemplo más simple, tomado del propio repositorio de Unleash, es una llamada condicional en Java:
if (unleash.isEnabled("nuevo-checkout")) {
renderizarCheckoutV2();
} else {
renderizarCheckoutV1();
}Qué hace: evalúa si el flag nuevo-checkout está activo para el usuario actual según la estrategia configurada en el panel. Si lo está, corre el camino nuevo; si no, el de siempre. La salida no es una respuesta HTTP, es un booleano que decide qué rama de código ejecuta ese request puntual.
En Node.js, el patrón típico es inicializar el cliente una sola vez al arrancar el servicio y esperar a que sincronice antes de evaluar nada:
const { initialize } = require('unleash-client');
const unleash = initialize({
url: 'http://localhost:4242/api/',
appName: 'checkout-service',
customHeaders: { Authorization: 'default:development.unleash-insecure-api-token' }
});
unleash.on('synchronized', () => {
console.log(unleash.isEnabled('nuevo-checkout'));
});Qué hace: descarga la configuración de flags desde la API local y, una vez sincronizado, evalúa nuevo-checkout sin pedirle nada a la red: el SDK guarda la configuración en memoria y la refresca en segundo plano. La salida esperada del console.log es true o false, nunca una promesa pendiente ni un error, porque la evaluación es puramente local.
Cómo empezar con Unleash en local
Hace falta tener instalados Git y Docker con Docker Compose incluido. En Windows, Docker Desktop necesita el backend WSL2 activado; en macOS alcanza con instalar Docker Desktop; en Linux se puede usar el daemon de Docker directamente, sin Desktop.
Con ambos instalados, los comandos son idénticos en las tres plataformas:
git clone [email protected]:Unleash/unleash.git
cd unleash
docker compose up -dEse comando descarga las imágenes y levanta el API, la base de datos Postgres y el panel de administración. Al terminar, hay que abrir http://localhost:4242 en el navegador y entrar con usuario admin y contraseña unleash4all: son las credenciales de desarrollo que trae el docker-compose.yml del repositorio.
⚠️ Ojo: admin/unleash4all es la credencial de desarrollo del docker-compose oficial. Cambiala antes de exponer la instancia fuera de tu máquina local.
Para conectar un SDK de frontend a esta instancia, la URL es http://localhost:4242/api/frontend/ y la clientKey es default:development.unleash-insecure-frontend-api-token. Para un SDK de backend, la URL base es http://localhost:4242/api/ con el token default:development.unleash-insecure-api-token. Ambos tokens son de desarrollo, y el propio nombre del token lo deja explícito con la palabra «insecure».
Para confirmar que un flag quedó activo sin depender del código, basta con abrir el panel admin, entrar al proyecto y mirar el toggle del flag en el entorno correspondiente: si está en verde, cualquier SDK conectado a ese entorno lo va a evaluar en true apenas sincronice. No hay un comando de una sola línea que lo confirme desde afuera sin pasar por esa pantalla o por el SDK mismo.
Casos de uso reales de los flags de features
El más común es el lanzamiento gradual: activar una función nueva para un porcentaje chico de usuarios, mirar las métricas de error durante un rato y subir el porcentaje solo si todo se mantiene estable. Si algo se rompe, se vuelve a cero sin ningún deploy.
El segundo es el programa beta cerrado: una estrategia de lista de usuarios muestra la función únicamente a los IDs que están en una lista específica, sin tocar nada más del comportamiento para el resto.
El tercero es el interruptor de emergencia para integraciones externas. Si un proveedor de pagos o de envío empieza a fallar, apagar el flag que llama a esa integración evita que el problema se propague al resto de la aplicación, en lugar de esperar un hotfix.
El cuarto es el experimento controlado: Unleash permite definir variantes dentro de un mismo flag, de forma que una porción del tráfico ve la versión A y otra porción ve la versión B, y cada SDK reporta qué variante le tocó a cada usuario para poder comparar métricas después.
Errores comunes y buenas prácticas
- Flags zombis: un flag que ya está al 100% hace meses y nadie borró del código. Cada flag debería tener una fecha de vencimiento y una tarea para limpiarlo.
- Dependencias cruzadas entre flags: si el flag B solo tiene sentido cuando A está activo, esa relación hay que documentarla, porque Unleash no la infiere sola.
- No testear las dos ramas: es común probar solo el camino con el flag activo y asumir que el código viejo sigue funcionando igual que antes.
- Tokens de backend en el cliente: el token con acceso a la API completa nunca debería llegar a un navegador; para eso existe el token de frontend, con permisos acotados.
- Estrategias sin asignación estable: un despliegue gradual por porcentaje sin un criterio estable, como el ID del usuario, puede mostrarle la función a la misma persona unas veces sí y otras no, lo que rompe la experiencia.
Comparativa: Unleash frente a otras formas de gestionar flags de features
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Unleash Open Source | Equipo que puede autohospedar y no necesita SSO corporativo | Gratuito, corre en infraestructura propia | El equipo administra backups, updates y alta disponibilidad |
| Unleash Enterprise | Organización que necesita RBAC, SSO y change requests auditados | Soporte, SCIM, control de acceso por rol | Es un plan comercial, no gratuito |
| Plataforma cerrada administrada por un proveedor | Equipo que prioriza soporte comercial sobre autohospedaje | Infraestructura administrada por el proveedor | Dependencia de un proveedor externo y de su esquema de precios |
| Flags hechos a mano en código o base de datos | Proyecto chico con uno o dos flags puntuales | Cero dependencias nuevas | No escala: sin panel, sin auditoría, sin segmentación real |
Profundizando: estrategias de activación avanzadas
La estrategia más usada en producción es el despliegue gradual con una asignación estable por usuario (stickiness): Unleash calcula un hash a partir del ID del usuario y el nombre del flag, así que la misma persona siempre cae del mismo lado del porcentaje mientras ese porcentaje no cambie. Sin esa consistencia, cada evaluación sería casi una moneda al aire distinta para el mismo usuario.
stateDiagram-v2
[*] --> Desactivado
Desactivado --> DespliegueParcial: activar por porcentaje
DespliegueParcial --> Activo: subir al 100 por ciento
DespliegueParcial --> Desactivado: revertir
Activo --> Desactivado: apagar el flagLas constraints agregan condiciones adicionales sobre esa estrategia: país, versión de la app, tipo de cliente o cualquier campo del contexto que envíe el SDK. Se pueden combinar varias constraints con una estrategia de porcentaje, de forma que, por ejemplo, el despliegue gradual solo aplique a usuarios de un país puntual.
Para equipos más grandes, la diferencia real entre la edición Open Source y Enterprise no está en el SDK ni en la evaluación del flag, eso es idéntico, sino en los procesos alrededor: según el repositorio oficial, Enterprise agrega control de acceso por rol, change requests, inicio de sesión único y SCIM para aprovisionar usuarios automáticamente, pensado para organizaciones donde un cambio de flag en producción necesita aprobación antes de aplicarse.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná el repositorio, corré docker compose up -d, creá un flag propio llamado mi-primera-prueba en el panel de localhost:4242 y leelo desde el SDK de tu lenguaje con la misma lógica del ejemplo de isEnabled().
Preguntas frecuentes
¿Qué es Unleash?
Unleash es una plataforma open source para administrar feature flags: expone una API central, un panel de administración web y SDKs oficiales para conectar aplicaciones de backend y frontend.
¿Cómo funcionan los flags de features en Unleash?
Cada SDK descarga la configuración de flags al iniciar y la refresca en segundo plano. Evaluar un flag dentro del código es una operación en memoria que consulta esa configuración local, no una llamada de red por cada chequeo.
¿Unleash es gratis?
La edición Open Source se puede autohospedar sin costo de licencia. La edición Enterprise, con control de acceso por rol, SSO y SCIM, es un plan comercial que según su repositorio ofrece una prueba gratuita de 14 días.
¿Qué diferencia a Unleash de una plataforma cerrada tipo LaunchDarkly?
Unleash tiene una edición open source que se puede instalar y correr en infraestructura propia sin costo de licencia. Una plataforma cerrada administrada por un proveedor no ofrece esa opción de autohospedaje gratuito, a cambio de no tener que operar el servidor.
¿Necesito Docker para usar Unleash?
Para probarlo en local conviene, porque docker compose up -d levanta el API, la base de datos y el panel en un solo paso. En producción también se puede instalar desde el código fuente con Node.js siguiendo la guía de contribución del repositorio, o usar la nube de Unleash Enterprise sin instalar nada propio.
Referencias
- Unleash en GitHub: repositorio oficial del proyecto, con instrucciones de instalación y los SDKs listados.
- Documentación oficial de Unleash: guías de configuración, estrategias de activación y referencia de API.
- Sitio oficial de Unleash: información sobre la edición Enterprise y la prueba gratuita.
- Feature Toggles, por Pete Hodgson: el artículo de referencia sobre el patrón de feature flags en el desarrollo de software.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Pankaj Patel en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios