Bruno

Last reviewed Aug 26, 2026 · 834 words

There is nothing to host. Bruno is a desktop application, and the reason it appears in a self-hosting directory is that it solves the Postman problem by refusing to have a cloud at all: every collection is a folder of plain-text .bru files on your disk, so version control, review, and sync are whatever your git remote already does. Install it on each developer's machine, commit the collection next to the code it tests, and you have replaced a per-seat Postman subscription with a repo. The 256 MB RAM figure in the catalogue is the Electron app itself, not a service.

The repo is the sync server

Postman's collaboration features exist because collections live in Postman's database. Bruno inverts that. One request is one file, one folder is one collection, and environments sit in an environments/ subfolder alongside them. A diff of a request change is a 3-line diff a reviewer can read, and two people editing the same collection get an ordinary merge conflict instead of a "who overwrote whom" mystery. Push it to Forgejo or wherever your code already lives and the collection travels with every clone.

The practical layout that works is a bruno/ directory at the root of each service repo, so the API tests version with the API. Cross-team collections that cover several services get their own repo. Either way, the mental shift is that a collection is code and gets reviewed like code, which is the thing Postman's "shared workspace" never quite managed.

The trap in all of this is committing credentials. Bruno environments have a concept of secret variables that are stored outside the collection files, but the pattern I trust more is a .env file in the collection root, read via {{process.env.API_TOKEN}} in requests, and a .env line in .gitignore from the first commit. Commit a .env.example with the key names and empty values so the next clone knows what to fill in. Do that before the first push, not after, because a token in git history is a token you rotate.

The CLI turns collections into CI checks

The under-advertised half of Bruno is @usebruno/cli, which runs a collection headlessly:

npm install -g @usebruno/cli
cd bruno/
bru run --env staging --reporter-junit results.xml

Because assertions live in the request files (a tests block with Chai-style expect() calls, or the declarative assert block for simple status and body checks), the same collection you click through in the app becomes a smoke test in a pipeline. A 40-request collection runs in a few seconds against a local service. It is the cheapest contract test you will ever add, and it is the reason to prefer Bruno over an API client that keeps its scripts in a proprietary format.

What the free version leaves out

Bruno's core is MIT-licensed and complete for individual use: requests, environments, scripting, assertions, GraphQL, collection import from Postman and Insomnia, and the CLI. The paid Golden and Ultimate editions add things like visual git operations inside the app, request history and inline documentation, and some team conveniences. Nothing in the paid tiers is needed to do the git workflow above, because git already does it. Pricing is a per-user licence rather than a monthly seat; check the current figures on usebruno.com before quoting them to a manager. The Postman alternatives page lays out how each replacement handles the team-sync question, which is the real difference between them.

If you want browser access, Bruno is the wrong shape

A few people arrive here wanting a hosted web UI a team can open from anywhere. That is not Bruno. Hoppscotch is the tool with a genuine self-hostable server, browser client, and shared workspaces, at the cost of running a database and an auth layer. The Bruno vs Hoppscotch piece draws the line: git-native desktop tool versus hosted web tool. Both are honest answers; they just answer different questions.

Installation, briefly

Native installers are on the download page for Windows, macOS, and Linux (deb, rpm, AppImage), plus brew install --cask bruno and snap install bruno. First launch, open a collection folder, and it just reads the files. Open an existing Postman export via Import and Bruno writes the .bru files for you, at which point your first commit is the migration done.

What I'd do

Install Bruno on every developer machine from the official installers, create a bruno/ folder in each service repo, gitignore .env before the first commit, and add bru run to the CI job that already runs the unit tests. Skip the paid tiers until someone can name the feature they are missing. If the requirement is a URL a non-developer can open in a browser, stop and set up Hoppscotch instead; forcing Bruno into that role wastes a week.