bruno is an open-source API client and IDE for exploring and testing REST and GraphQL endpoints, designed for authorized testing, development, and CI/CD automation without cloud sync.

bruno positions itself as a deliberate rejection of the cloud-centric API client model dominated by Postman and Insomnia, and the repository's README makes that philosophy explicit in the first paragraphs. Collections are stored as plain files in a folder on your filesystem, described in a custom markup language called Bru, which means every request, environment variable, and assertion is text that diffs cleanly. For security teams and development groups that have grown uncomfortable shipping their internal API surface descriptions to a third-party cloud, this local-first architecture is the entire pitch, and it is one worth taking seriously.

The technical decision that defines bruno is the Bru format. Instead of a proprietary JSON blob or a database-backed workspace, each request lives in a .bru file that can be committed to Git or any other version control system. This has second-order effects that matter operationally: collection history becomes reviewable, changes to a test suite go through the same pull-request workflow as application code, and a senior reviewer can see exactly which request a junior engineer modified before it ever runs against a shared environment. The README calls this 'collaborate via Git', and it is arguably the feature that distinguishes bruno most sharply from its commercial competitors.

The other architectural commitment is offline-only operation. The README is unusually blunt on this point: there are no plans to add cloud sync, ever, framing data privacy as a design principle rather than a roadmap item, and pointing to a public discussion thread on the repository for the long-term vision. For authorized assessment work, this matters in a practical way — request collections built during an engagement, including headers, tokens, and environment variables, never leave the analyst's device unless the analyst explicitly chooses to commit them. That is a meaningfully smaller blast radius than cloud-workspace clients where a misconfigured shared team can leak internal API maps.

Installation is broadly available across platforms. The README documents binary downloads from the project website for Mac, Windows, and Linux, plus package-manager coverage that reads like a checklist: Homebrew, Chocolatey, Scoop, winget, Snap, Flatpak, AUR, and a signed Apt repository. The simplest invocation is brew install bruno on macOS or choco install bruno on Windows. The breadth of packaging, combined with the MIT license and a repository sitting at roughly 47,000 stars with JavaScript as the primary language, signals a mature, actively maintained project rather than a hobby client.

The part of the tooling most relevant to automated and authorized testing workflows is the Bruno CLI, distributed on npm as @usebruno/cli and installed with npm install -g @usebruno/cli. Once installed, the bru binary runs collections headlessly: bru run executes every request in a collection, bru run request.bru executes a single request file, and bru run folder --env Local targets a folder against a named environment. This is the bridge between interactive API exploration and regression testing, and it is what makes bruno a plausible component in a sanctioned CI/CD pipeline rather than just a developer convenience.

The CLI story extends into containerized execution. Official Docker images for the CLI are published to both Docker Hub as usebruno/cli and the GitHub Container Registry as ghcr.io/usebruno/cli, with alpine and debian variants covering linux/amd64 and linux/arm64. The README's Docker example mounts the working directory and runs docker run -v $(pwd):/bruno usebruno/cli run, which means a collection can be executed in CI without installing Node.js or npm on the host at all. The documentation references CI examples for GitHub Actions, GitLab CI, and Jenkins, indicating the maintainers treat pipeline integration as a first-class use case rather than an afterthought.

Repository metadata reinforces the developer-tool orientation. The topic list includes api-client, api-testing, http-client, graphql-client, openapi, openapi3, rest-api, and testing-tools, which sketches the intended surface: interactive HTTP and GraphQL request building, OpenAPI-aware workflows, and scripted test assertions across collections. The README itself is lighter on feature enumeration than many projects — its structure leans on screenshots, the vision discussion, and links to external documentation at docs.usebruno.com — so professionals evaluating it should expect the detailed scripting and assertion reference to live in the docs site rather than the in-repo README.

The sustainability model deserves a note because it shapes what teams can depend on. The majority of features are free and open source under MIT, while the maintainers sell paid versions with additional team-oriented functionality, explicitly framing the split as a balance between open-source principles and sustainability. The trademark for the name is held by the founder, Anoop M D, and the logo derives from OpenMoji under a CC BY-SA 4.0 license. For organizations doing procurement review, this is a conventional open-core arrangement: the core client and CLI remain permissively licensed, with commercial tiers funding development.

From a defensive and operational standpoint, bruno is fundamentally a client tool, not an attack framework — it sends the HTTP requests you define, nothing more. Its relevance to security work is threefold. First, it is a clean environment for reproducing and documenting API behavior during authorized assessments, with every request captured in reviewable text. Second, the Git-native collection format creates an auditable record of what was tested and when, which is valuable when an engagement report needs to show methodology. Third, its offline posture means internal API topologies described in collections stay on the machines of the people authorized to see them.

Defenders should understand the telemetry profile in reverse terms: because bruno is offline-only with no cloud sync, there is no vendor-side activity trail — the observable footprint is entirely on the targets being probed, in the form of ordinary HTTP request logs. A bruno collection in a compromised repository could serve as a map of internal API endpoints, credentials in environment variables, and auth headers, which argues for treating committed .bru collections as sensitive material in secret-scanning policies, exactly as one would treat .env files or Postman exports.

The project also shows the hygiene markers of a serious maintenance effort: a CI badge referencing test workflows on the main branch, a commit-activity badge, a roadmap, an active Discord community, and README translations into more than twenty languages. Combined with the CLI and Docker release cadence tied to every CLI publish, the practical risk of adopting bruno as a team standard looks low, and the migration path from existing clients is well-trodden territory in the community discussions the README links to, including a testimonials thread and a knowledge hub.

The verdict for an authorized professional is straightforward. If your workflow involves exploring, documenting, or regression-testing APIs — whether you are a developer verifying an OpenAPI spec, a QA engineer wiring collections into GitHub Actions, or a security consultant recording reproduction steps for a client report — bruno offers that capability with a data-residency posture that cloud clients cannot match. Install the desktop app from your platform's package manager, keep collections under version control, treat environment files containing tokens as secrets, and the tool earns its place in an authorized pipeline with minimal overhead.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside byd-dolphin-hacking: mapping the BYD Dolphin infotainment stack from ADB to the CAN bus


• Claude-Red for priming AI assistants with red team methodology


• Automating masscan and nmap workflows with spoonmap for authorized network discovery