Bruno stores collections as plain-text Bru files
Each request lives in an ordinary folder as a plain-text Bru file, which means a collection can sit beside the application it describes. A teammate can inspect a diff, comment on a pull request, and restore an earlier revision with the same version-control habits used for source code. That is a concrete improvement over passing exported collection files around or placing the only shared copy in a vendor account.
The project makes a firm trade: Bruno is offline-only, and its README says cloud sync will not be added. That keeps collection data on the user's machine and avoids making an account part of basic API work. It also means collaboration happens through Git rather than live presence, shared comments, or automatic workspace updates. A team already comfortable with branches and pull requests may prefer that. A support or QA group expecting Google Docs-style collaboration probably will not.
Packaged installers avoid the 1,956 MB dependency tree
Bruno publishes desktop downloads for macOS, Windows, and Linux, and the README documents Homebrew, Chocolatey, Scoop, winget, Snap, Flatpak, AUR, and Apt routes. That breadth makes the packaged application approachable even if the codebase behind it is large. The separate @usebruno/cli package can run a whole collection, one request, or one folder against a named environment.
Automation is credible too. Official CLI images are published to Docker Hub and GitHub Container Registry in Alpine and Debian variants for amd64 and arm64. Mount a collection into the container and the same files used in the desktop app can run in CI. One distinction matters: our repo scan found no Dockerfile in the 4,224-file checkout. Bruno provides built CLI images, but this source tree does not present a root Docker build as the contributor entry point.
What happened when we ran it
Our sandbox installed commit 6759656 successfully in 97 seconds on 3 CPUs with 8 GB of RAM using Node 22 on Debian. npm pulled 3,430 packages, and the installed tree occupied 1,956 MB. The repository itself was 22.6 MB checked out, with about 429,917 lines of source, so the dependency footprint is far larger than the files a contributor initially clones.
There was no root build script or target for our harness to call, so the build step was skipped. The same was true for tests: the repository has a tests directory and 7 CI workflow files, but our harness found no test script or target and skipped that step. This does not say the project has no tests. It says a fresh source checkout did not expose the standard commands our run looks for, which makes local verification less obvious than the end-user install.
The npm audit reported 26 known vulnerabilities: 1 critical, 12 high, 6 moderate, and 7 low. An audit result is not proof that the desktop application exposes every advisory, and we did not trace reachability. It is still enough to stop a security-sensitive team from treating the source install as clean. Review the affected dependency paths and the current lockfile before using the monorepo as a base for internal extensions.
Issue #8928 reports lag around 500 variables
Bruno covers the expected daily workflow: desktop requests, file-backed collections, environments, scripts, and headless collection runs. Version 4.1.0, released on August 20, 2026, added a mock server, more variable controls, YAML migration work, and preservation of scripts during Postman import and export. Those changes show a product moving beyond a minimal request sender into documentation, migration, and team workflow territory.
The growing surface has sharp edges. Open issue #8928 reports severe lag when a collection has about 500 variables, including high CPU use while typing and saves that can take minutes. That is a specific limit worth reproducing if your team carries large generated environments or shared variable catalogs. The same issue was still active on August 25. Smaller collections may never hit it, but the report makes a company-wide rollout without a representative import test a bad bet.
August 2026 activity outweighs the 1,824-item queue
The repository was pushed on August 25, 2026, five days after v4.1.0 shipped. Issues were being opened, updated, and closed that same day, including work around collection migration, OAuth behavior, memory use, and long-standing interface bugs. GitHub showed 1,824 open issues and pull requests combined. That is a large queue, but it is not 1,824 confirmed defects, and the dated activity does not resemble an abandoned project.
Documentation is strongest for users. The README separates desktop packages, npm CLI use, official containers, commercial versions, and links to the full command reference. It is less direct for contributors: our run encountered a monorepo with no root build or test target that matched the harness, despite the visible CI and test structure. People evaluating Bruno as a tool have a short path. People modifying Bruno should budget time to learn the workspace-specific commands and dependency layout.
Bruno fits teams that use Git for collection sync
The recommendation is strongest for a development team that wants collection changes to travel with code changes. The offline rule is clear, the desktop distribution covers 3 operating-system families, and the CLI gives those files a route into CI. No cloud account is required for the core workflow.
That recommendation narrows if your team needs instant shared state or routinely opens collections with hundreds of variables. The 3,430-package install and 26 audit findings also make source-level adoption a different decision from installing the desktop release. Start with a packaged build, import one real collection, run it through the CLI, and test the largest environment your team owns. If Git already carries your collaboration, Bruno fits. If Git feels like a workaround for the collaboration you want, choose a client built around shared workspaces.