The request collection is code, so treat it like code

Anyone who has used an API client for a few years carries the same quiet grievance. The collection of requests lives inside an account system, so lending it to a colleague means exporting and importing. When an endpoint changes, nobody notices. Handover happens by voice, and the newest person on the team inherits a folder they cannot open. Bruno answers with something almost rude in its simplicity: every request is a plain text file on your own disk. A collection is a folder, a request is a file, and once that folder sits in a repository the whole Git routine works unchanged, commit, branch, review and rollback.

The consequence is not cosmetic. An interface change appears as a diff in code review, so the conversation about it happens where the change is rather than in a chat thread three days later. Nobody has to remember to tell anybody. The collection simply becomes code, and code tends to be read by whoever touches it next. That sounds like a small detail until the first handover, when the old owner has left and the only remaining description of how an endpoint behaves is the request that calls it.

Offline first, and the promise sits in the architecture

Bruno is one of the few tools that wrote no cloud into the product promise instead of a footnote. The official documentation says plainly that there is no cloud sync on the roadmap and no mandatory account: the data lives on your machine and keeps working offline, including on a train or behind a client network that blocks everything.

That promise would be cheap if it hid a thin feature set, and it does not. REST, GraphQL, gRPC and WebSocket are all covered, environment variables are layered so development and staging do not collide, scripts carry pre and post logic, and version 4 added a native AI assistant for drafting requests and tests, typed variables and a rebuilt secret manager. Team plans can point secrets at external vaults so credentials never land in the repository. The core is MIT licensed, paid tiers sell collaboration rather than access, and neither the file format nor the command line tool is restricted.

Version 4.1 arrived in 2026-08 with a built in mock server and rich text documentation editing, and releases still land several times a month. The project also collected a trade show award, which matters less than the migration path: the importer reads collections exported from tools that force an account, and the .bru format stays readable text, so a review diff is legible at a glance instead of being a wall of generated identifiers.

What a working day looks like, and where the price sits

A day in Bruno is unremarkable, which is the compliment. Open the workspace folder, pick an environment, fire a request, save the response as an example, and that example becomes a test which later runs headless from the command line. Because the collection is a folder of files, a colleague can clone it and run the same suite without asking a vendor for permission or waiting for an invitation mail. The mock server closes the other half of the loop: a front end can be built against a saved response before the real endpoint exists, which is exactly the period when teams usually improvise.

Where it fits badly is worth naming too. A team that wants hosted sharing, browser access and a polished dashboard for people who are not engineers will find Bruno too raw; it assumes you know what a repository is and are willing to use one. That is a real filter rather than a flaw, but it decides who enjoys the tool and who fights it.

No cloud sync means moving a collection between machines is your job: a Git remote, a network drive, an archive you copy yourself. For teams already living inside version control that is the point rather than the price. For one person who only wants a phone client and a laptop client to agree without thinking about it, it is a step backwards, and it is fair to say so out loud.

The popularity of Bruno confirms something the tool market keeps forgetting: the end state of a developer tool is not moving everything to the cloud, but returning the choice. Collections as code, data on your own disk, protocols genuinely open. Put those three together and it becomes one of the default answers for how a team shares an interface.