Git can review your API requests alongside your code
Change an API request in Bruno and you change a file your teammate can review in Git. The project README describes collections as folders on your machine, with requests stored in the readable Bru format. That makes Bruno attractive when requests should follow the same branch and approval process as the code they exercise. You can inspect a changed URL or header before accepting it.
The application behind that simple workflow is substantial. Our checkout contained 4,962 files and roughly 505,043 lines of source in 24.8 MB, organized as npm workspaces. For someone choosing an API client, the distinction matters: using a desktop download and maintaining a fork involve different commitments. I'd choose Bruno for the collection files first. Its source footprint gives a developer considering custom changes another cost to weigh.
What happened when we ran it
Our run installed Bruno commit 001e2b9 in 198 seconds, adding 3,362 packages and occupying 1,767 MB on disk. We cloned it on October 11, 2026, in a fresh Debian sandbox with 3 CPUs and 8 GB of RAM, using the lab-node:22 image. The container had no secrets or elevated privileges. Installation succeeded, so the dependency setup cleared that particular hurdle.
Build and tests were skipped because the lab found no build or test script or target to run. The scan did find a tests directory and 7 CI workflow files. Those observations can coexist: the repository contains testing material, while this run produced no passing suite or compiled application. The supplied measurements establish a successful install. They leave desktop startup and request execution unverified.
Npm audit reported 170 known vulnerabilities: 4 critical, 84 high, 71 moderate, and 11 low. That deserves attention before adopting a source fork or copying its dependency setup into your own infrastructure. The summary does not identify affected packages or reachable code paths, so it cannot establish which findings affect the distributed desktop app. It also found no Dockerfile in the measured checkout.
Local secret values stay out of collection exports
Since v4.0.0, Bruno displays secret variables in a separate tab, according to its secret-variable documentation. Marking a variable as secret keeps its value out of the environment file and collection export. Bruno stores those values locally, using operating-system encryption where available and an AES256 fallback. That's a useful separation when the same collection needs a developer's token on a laptop and different credentials in CI.
It also creates a handoff you must handle yourself. Committing the request files doesn't deliver a teammate's secret values. Supply credentials separately, and review what remains in the files before pushing them. A token pasted directly into a request still needs your attention. For an ordinary local collection, the documented workflow needs no hosted Bruno service, but authenticated target APIs still require their own credentials and reachable endpoints.
External packages require a more permissive script mode
Bruno CLI v3.0.0 changed the default script runtime to Safe Mode. The CLI reference says external npm packages and filesystem access require an explicit --sandbox=developer flag. Collections can run through bru run, with a selected environment, and the CLI documents JSON, JUnit, and HTML reports. This is a practical route from a collection in Git to repeatable API checks, provided its scripts work under the chosen runtime.
Release v4.2.1, published September 30, 2026, explains why the scripting boundary deserves scrutiny. Its security notes describe resolving real filesystem paths in QuickJS to prevent access outside the intended location and removing a loader exposed to user scripts. The maintainers recommend upgrading. Those fixes are separate evidence from our 170 audit findings. Neither source says that this release clears every dependency advisory we measured.
Cloud collaboration is outside Bruno's stated direction
The README explicitly rules out cloud sync, including future plans for it. If your team wants shared collections to update through a hosted workspace without learning Git, that is a reason to choose another client. Hoppscotch documents shared team collections and cloud sync. Insomnia supports local, Git, and cloud storage, with account and subscription conditions worth checking. Bruno suits a team that already accepts branches, commits, and merge conflicts as collaboration tools.
Free software also doesn't mean every commercial feature is included. Bruno's edition comparison separates the open-source client from paid editions and lists community support for the free option. Check that matrix before promising an organization a particular integration or support response. The 1,767 MB in our sandbox belongs to the source installation, not a measured desktop download. Use the published Mac, Windows, or Linux packages for an ordinary trial rather than treating our checkout as the required user setup.
October 12 activity shows maintenance, not a clean bill of health
The last push was October 12, 2026. GitHub's API returned 47,472 stars and 1,868 open issues and PRs, while issue updates and code proposals were active that same day. Combined with September's security release, that shows ongoing maintenance. It doesn't turn the backlog into a count of confirmed bugs or show how quickly your own report will be handled. Our 7 detected CI workflows likewise show automation exists, without supplying a passing result for this commit.
I'd start with a representative collection that includes your actual authentication and scripts. Have a teammate review its files, supply separate secrets, and run it through the CLI. If that handoff feels natural, Bruno's storage model has earned its place. If you need everyone to work through a cloud workspace, pick a client that supports that workflow now.