Bruno: an offline API client that keeps collections in plain files

What Bruno solves, and who it is actually for

Postman-style clients keep collections inside an application database or a hosted account. That makes them awkward to review. A change to an endpoint path or an auth header is invisible in a pull request because it lives in a binary store or a server somewhere. Bruno takes the opposite position: the README states that it stores collections directly in a folder on your filesystem and uses a plain text markup language, Bru, to save information about API requests.

The target user is a backend or platform engineer who already treats configuration as code. If your team reviews Terraform, Kubernetes manifests and migration files in the same review tool, adding .bru files to that flow costs almost nothing. The requests become diffable, blameable and revertable alongside the code they exercise.

The README is explicit about scope: "Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever." That is a design commitment, not a missing feature. It also tells you who should look elsewhere: anyone whose workflow depends on a shared hosted workspace with role-based access, or on opening a collection from a browser on a machine where nothing is installed.

How a Bru collection is stored and executed

The repository is an npm workspace monorepo. The root package.json lists the workspaces, and they map closely onto the architecture: packages/bruno-app for the UI, packages/bruno-electron for the desktop shell, packages/bruno-cli for the command line runner, packages/bruno-lang for the Bru language itself, packages/bruno-filestore and packages/bruno-sqlite for storage, plus converters, schema, query and js packages.

That split matters when you evaluate the tool. The desktop app and the CLI are separate packages that read the same collection format, which is why a collection you build by clicking in the UI can be executed in a pipeline with bru run. The presence of bruno-converters suggests import and export paths from other formats, though the README does not enumerate them.

The data flow is file-first. A request lives as a .bru file in a directory, the directory is the collection, and version control is whatever you already use. The README says you can use Git or any version control of your choice to collaborate over your API collections. Nothing in the described flow requires a server to be reachable for the collection to be readable, which is the practical consequence of the offline-only stance.

Installing Bruno and running your first collection

The README points to binary downloads for Mac, Windows and Linux at usebruno.com/downloads, and also documents package manager installs. On macOS with Homebrew the command is a single line. After it completes, bruno should resolve on your PATH and the desktop app should appear in your applications.

brew install bruno

Windows users have three documented options. Chocolatey, Scoop and winget are all listed in the README, so pick whichever your machine already uses.

choco install bruno

scoop bucket add extras
scoop install bruno

winget install Bruno.Bruno

Linux is covered by Snap, Flatpak and the AUR, and the README also shows an Apt path that writes a keyring file to /etc/apt/keyrings/bruno.gpg before the repository is added. The Apt snippet in the README is truncated mid-pipeline, so read the full instructions on the project site rather than copying that block as-is.

For automation, the CLI is a separate npm package. Install it globally, then change into the directory that holds your collection and run it.

npm install -g @usebruno/cli
bru run

To run one request, or a folder against a named environment, the README gives these forms. The --env flag takes the environment name as it appears in your collection.

bru run request.bru
bru run folder --env Local

If you would rather not install Node on the machine, official Docker images are published to Docker Hub and the GitHub Container Registry on every CLI release, with alpine and debian variants for linux/amd64 and linux/arm64. Mounting the current directory gives the container the collection to execute.

docker run -v $(pwd):/bruno usebruno/cli run

The offline-only decision is also the main limitation

The same property that makes Bruno pleasant for Git users makes it the wrong tool in several common situations. There is no cloud sync, by stated intent, so a colleague cannot open a shared workspace and see your latest request without pulling the repository. If your organisation's API work is done by people who do not have the repo cloned, or who are not comfortable with Git, the file-based model becomes friction rather than an advantage.

Secrets are the second constraint. Because requests and environments are plain files, anything you paste into them is a candidate for committing. The README does not describe a secrets manager, and it does not document an ignore strategy for environment files. Treat that as your responsibility and verify your .gitignore before the first push.

The README also does not document rollback, migration between major versions, or what happens to a collection when the Bru format changes. The repository has a bruno-schema and bruno-schema-types package, which implies validation exists, but the README does not explain backward compatibility guarantees. If you are converting a large existing collection, that gap is worth resolving before you migrate.

Finally, the README states that most features are free and open source while paid versions exist. The open source client is not the whole product surface, so check the pricing page against your requirements rather than assuming everything you see in screenshots is in the MIT build.

Bruno vs Postman: the difference is where the collection lives

The comparison people actually search for is Bruno vs Postman, and the honest answer is narrower than the marketing suggests. Both send HTTP requests, both let you organise them into collections, and both support environments and scripting. The divergence is storage and collaboration.

Postman's model centres on an account and a hosted workspace, with the client as the interface to that workspace. Bruno's model centres on a directory of text files, with the client as an editor for that directory. Everything else follows from that. Sharing in Postman is an access-control problem; sharing in Bruno is a merge conflict problem, which most engineering teams already know how to solve.

Insomnia is the other client the README names as a point of comparison. The README describes Bruno as a lightweight alternative to both, and the offline-only stance is the clearest expression of that positioning.

The trade-off is real in both directions. A hosted workspace gives you presence, comments and permissions without any repository discipline. A file-based collection gives you review, history and portability without any vendor dependency. Neither is strictly better; they optimise for different teams. If your API work is done by a group that already lives in Git, Bruno removes a step. If it is done by a group that does not, Bruno adds one.

Maintenance, licensing and what the release cadence tells you

The repository is not archived, and the last push was on 2026-08-20, the same date as the v4.1.0 release. The two preceding releases, v4.0.0 and v3.5.3, landed in July 2026. That is a project shipping major and minor versions close together, including a v4.0.0, which is the kind of release that typically carries breaking changes. If you pin a version, read the release notes for that major before upgrading across it.

The licence is MIT. That is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the licence and copyright notice are preserved. Two caveats sit outside the licence itself. First, the README states that Bruno is a trademark held by Anoop M D, so the permissive code licence does not grant you the name. Second, the README says majority of features are free and open source and points to paid versions, which means the MIT grant applies to the open source code, not to every feature you might see advertised. The logo is sourced from OpenMoji under CC BY-SA 4.0, a different licence from the code. None of this is legal advice; read license.md and the pricing page if you plan to redistribute or embed the client.

The upgrade cost is mostly the collection format. Because collections are plain text under your control, a format change shows up as a diff rather than a silent migration, which is easier to audit but still work. Budget for reviewing that diff on a major version bump.

Editorial conclusion

Adopt Bruno if your team already reviews code in Git and you want API requests to travel through the same pull-request path, with no cloud account involved. Skip it if you need hosted collaboration, shared workspaces, or a browser-based client, because the README states there are no plans to add cloud sync. Before you commit, verify three things: that your .bru files diff cleanly in your review tool, that the CLI version you install matches the desktop app you and your colleagues are running, and that any secrets you put in environment files stay out of the repository. The MIT licence covers the open source code; the paid versions and the Bruno trademark sit outside it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes