Bruno, la alternativa gratuita open-source a Postman
Introducción al protocolo API 🚀
En el día a día de cualquier desarrollador web, las APIs se han convertido en la forma natural de hablar con casi todo: desde el backend de tu propia aplicación hasta servicios externos como pasarelas de pago, plataformas de correo o integraciones de terceros. Una API no es más que un contrato: tú envías una petición con un determinado formato y el servidor te devuelve una respuesta que debería ajustarse a lo que promete la documentación. Detrás de ese intercambio, normalmente sobre HTTP, hay un lenguaje común basado en métodos como GET, POST o PUT, cabeceras, códigos de estado y, cada vez más, estructuras JSON que viajan de un lado a otro.
Ese contrato es sencillo sobre el papel, pero en la práctica probamos APIs en mil situaciones: endpoints en desarrollo, versiones nuevas, cambios de autenticación, pruebas de regresión o automatización de flujos completos. Ahí es donde entran en juego los clientes de APIs: herramientas que nos permiten construir peticiones, organizarlas en colecciones, jugar con variables de entorno y hacer pequeños tests automatizados sobre las respuestas. Durante años, Postman ha sido la navaja suiza de referencia para este trabajo, al punto de convertirse en casi un estándar en equipos de desarrollo.
Con el tiempo, sin embargo, el propio ecosistema de APIs ha madurado y también lo han hecho nuestras expectativas sobre las herramientas. Ya no queremos solo "probar un endpoint", sino integrar ese flujo en el control de versiones, compartir colecciones con el equipo sin depender de una nube propietaria o automatizar tests en CI/CD.
Es en este contexto donde empiezan a cobrar fuerza alternativas que replantean el modelo, tanto a nivel técnico como de licencias y privacidad.
Postman y los recientes cambios en licencias
Postman empezó como una extensión ligera para Chrome y terminó convirtiéndose en una plataforma completa para el ciclo de vida de las APIs: cliente de pruebas, documentación, monitorización, mock servers, gestión de equipos y espacios de trabajo compartidos en la nube.
El cliente de escritorio sigue siendo potente, con soporte para métodos HTTP habituales, autenticaciones como Basic, Bearer u OAuth, variables de entorno y ejecución de colecciones encadenadas con scripts de pre y post petición en JavaScript. Con esa evolución, lo que antes era una herramienta de escritorio casi "offline" se ha ido orientando cada vez más a un modelo conectado y de suscripción.
Esa orientación se refleja de forma muy clara en sus cambios de licencia y límites de uso. En los últimos años, Postman ha ido acotando progresivamente algunas capacidades avanzadas en los planes gratuitos, empujando hacia planes de pago para funcionalidades que antes dábamos por sentadas.
Un ejemplo concreto es el límite de ejecuciones de colecciones con Collection Runner: desde mayo de 2024, los usuarios de todos los planes sin el add‑on específico están limitados a 25 ejecuciones al mes por usuario con la licencia base, algo que antes funcionaba con un modelo de 250 ejecuciones por equipo y mes en determinados planes profesionales y enterprise.
Más allá de los límites de ejecución, también ha habido cambios en el modo en que se gestionan los espacios de trabajo privados y las capacidades de colaboración, que ahora están más ligadas a los niveles de plan contratados y a la estructura de roles dentro del equipo.
La consecuencia práctica es que, si utilizas Postman fuera del paraguas de una organización que pague una suscripción, es fácil encontrarse con notificaciones, restricciones en visibilidad de workspaces o problemas a la hora de compartir colecciones, incluso aunque tus datos sigan siendo técnicamente tuyos.
Esta deriva hacia una plataforma‑servicio tiene sentido desde el punto de vista de negocio, pero choca con ciertos flujos de trabajo. Si tu prioridad es mantener un stack ligero, con proyectos versionados en Git y sin depender demasiado de servicios externos, cada nueva limitación, cambio en los términos o elemento "cloud first" te introduce un pequeño problema adicional. Y cuando este problema entra en el propio núcleo de cómo pruebas tus APIs, es lógico que empieces a mirar alternativas que mantengan el foco en el cliente de escritorio, los archivos locales y un modelo de uso más predecible.
¿Qué es Bruno?
Bruno aparece precisamente como respuesta a ese escenario: es un cliente de APIs open source pensado como alternativa ligera a Postman o Insomnia, con una filosofía muy clara de "offline first" y control local de los datos. En lugar de almacenar tus colecciones en la nube de un proveedor, Bruno guarda toda la información de tus peticiones en carpetas de tu propio sistema de archivos.
Para describir esas peticiones utiliza un formato de texto plano llamado Bru, un pequeño lenguaje de marcado que vive junto a tu código y que puedes versionar con Git o cualquier otro sistema de control de versiones que uses en tus proyectos.
Esa decisión de diseño tiene un impacto directo en el flujo de trabajo de un desarrollador web acostumbrado a trabajar con repositorios: tus colecciones dejan de ser "algo" que está en una cuenta online y pasan a ser parte del propio proyecto, como el código fuente o la configuración de entorno. Puedes hacer branching, PRs, code reviews y revertir cambios sobre tus colecciones de APIs con la misma naturalidad con la que gestionas el resto del código.
Además, Bruno funciona sin conexión a internet y sus creadores han sido explícitos al afirmar que no tienen intención de añadir sincronización en la nube en el futuro, reforzando esa apuesta por la privacidad y la propiedad local de los datos.
A nivel funcional, Bruno no se queda corto. Soporta peticiones HTTP con distintos métodos, gestión de colecciones y carpetas, variables de entorno con diferentes alcances, scripts de pre‑request y tests de respuesta en JavaScript, así como autenticaciones habituales y capacidades de importación desde Postman, OpenAPI o Insomnia.
Todo esto se presenta en una interfaz que quiere resultar familiar a quien viene de Postman, pero que se apoya en un modelo de archivo en disco más cercano a cómo pensamos un editor de código que a una aplicación SaaS tradicional.
Además del cliente de escritorio, el ecosistema incluye un CLI que permite ejecutar peticiones y colecciones desde la línea de comandos, generar informes de pruebas en formatos como JSON, JUnit u HTML e integrarse con pipelines de CI/CD. Esto facilita que las mismas colecciones que diseñamos visualmente puedan servir como base de suites de regresión automatizadas que se ejecutan en cada push o en cada despliegue, sin tener que reescribir la lógica de pruebas en otro lenguaje.
Bruno frente a Postman: licencias y uso 📃
La gran diferencia entre Bruno y Postman no está solo en la interfaz, sino en el modelo mental que proponen sobre dónde viven tus colecciones y bajo qué condiciones puedes usarlas.
Postman opera cada vez más como una plataforma centrada en la nube, con planes, límites mensuales, workspaces y un conjunto de servicios que se activan o restringen según tu licencia. Esto es útil si trabajas en una organización grande que paga por ese ecosistema, pero introduce complejidad cuando simplemente quieres un cliente de APIs robusto que puedas abrir en tu portátil, sin preocuparte por límites de ejecución o por la visibilidad de tus espacios privados en función del plan.
Bruno, por el contrario, plantea un modelo muy cercano a cómo trabajamos ya con editores de código y repositorios: tus colecciones son archivos de texto plano, versionables, que viven en tu sistema de archivos y que se integran sin complicación en Git. No hay sincronización en la nube ni intención de introducirla, lo que implica que no estás sujeto a cambios repentinos en políticas de almacenamiento, licencias o límites de uso impuestos por un servicio centralizado. Esto lo convierte en una opción especialmente atractiva para proyectos personales, equipos que quieren mantener un stack ligero o entornos donde la privacidad de los datos es prioritaria.
En términos de licencias, este enfoque open source y offline implica que puedes adoptar Bruno sin tener que negociar con un modelo de suscripción ni ajustar tu forma de trabajar a los planes de un proveedor. Si necesitas colaboración, la haces a través de Git; si necesitas automatización, tiras del CLI y lo integras en tu pipeline. Y si en algún momento decides dejar de usarlo, te llevas contigo todas tus colecciones, que siguen siendo simples archivos de texto bajo tu control.
Migrar desde Postman a Bruno encaja perfectamente con una filosofía de herramientas minimalistas: menos dependencia de servicios externos, más control sobre el repositorio y una curva de aprendizaje razonable si vienes de Postman.
📊 171