Bruno keeps API collections in Git, not in the cloud

At many client companies, the security team’s first question about any new tool is: where does the data go? With Bruno, the answer is much shorter than usual. Bruno’s home page states it outright: no cloud sync, no accounts, no sign-in.

For a forward deployed engineer, that detail matters more than any feature. There are no accounts to provision and no vendor server holding the collection, so the list of things to justify to security gets shorter too.

The API requests you build up while working on an integration with the client’s engineers become a record of how the two systems talk to each other, and that record needs to live where both teams can see it.

The collection is files, not a cloud workspace

The official documentation describes Bruno as a Git-friendly, offline-first API client. According to the README on GitHub, Bruno stores collections directly in a folder on disk, with each request written in Bru, a plain-text markup language.

Because it is plain text, that folder can sit inside the code repo. Bruno’s documentation says the readable format lets developers see at a glance what has changed in a collection. The README also says you can use Git or any other version control system.

This is the core difference from tools that keep collections on the vendor’s servers. Bruno’s own comparison page, which is to say the vendor’s view, sets Postman’s cloud storage model with sign-in against Bruno’s local desktop app model, in which the concept of an account does not exist.

One developer writing on DEV Community said they switched to Bruno after struggling to version-control a large Postman collection file in Git.

An example: adding an endpoint to an integration project

Imagine you are connecting your system to a client’s orders API. The project repo has a folder of integration code and, next to it, a Bruno collection folder holding the requests: get a token, list orders, create a test order. Each request is its own Bru file.

The client has just added a status filter parameter to the list-orders endpoint. You create a new branch, edit the request in Bruno and save it. Git records one small change in one text file, exactly as Bruno’s home page describes: branch, diff, review and merge your API collections.

You open a pull request. The client’s engineer reads the diff, sees a single added parameter line, checks it against their documentation and approves. When they pull main, the new request is already in Bruno on their machine. Nobody has to email an export or invite anyone into a workspace.

The real value is that the API change and the code change travel in the same pull request. Reviewers see both, and the Git history can answer the question that comes up three weeks later: who changed this request, and why?

Secrets are the easiest place to trip

If the collection is in Git, everything in the collection can end up in Git too. Bruno’s documentation is explicit: whether you share through source control or by exporting, secrets must be removed from the collection first. Secrets are stored locally on the machine.

The cleanest approach is to separate values from requests entirely: the request files in the repo hold only the variable names for tokens or API keys, while the real values live on each person’s machine.

If you need to store those values in a file, keep that file outside the repo or list it in .gitignore, following the usual Git convention. Agree this with the client team before the first commit, so that each person supplies credentials for their own machine.

One more concrete habit: before every push, run git diff --staged on the collection folder and look for strings such as Bearer, token or api_key. If you see a real value instead of a variable name, remove it before committing. It takes a few seconds; scrubbing a token out of Git history takes far longer.

When is Bruno the wrong choice?

The project’s README says plainly that Bruno is offline-only and will never have cloud sync. If the client team is used to a shared workspace that updates instantly and requires no Git knowledge, they will have to change their habits. An operations team that rarely touches a repo will need time to adjust, and you should build that into the plan.

The README also says most features are free and open source, while paid commercial editions add more. Before promising the client anything, check which edition the features you need belong to.

What to learn first, and how to put it on a CV

The thing to learn first is not Bruno’s interface but the Git discipline around it: where the collection folder sits in the repo, the convention for reviewing API changes, and how to keep secrets out of committed files. If you already work through pull requests, most of this workflow will feel familiar.

When writing a CV or answering FDE interview questions, don’t just write “used Bruno”. Say that you put an API collection in a repo shared with the client team, reviewed changes through pull requests and kept secrets out of Git history. Recruiters can read both integration skill and security awareness in that.

A tool that sends nothing outside has fewer questions to answer from the client’s security team. Bruno is betting on exactly that, and the rest depends on how clean you keep the repo.