Bruno

Bruno is the API client for engineers who don't want their requests living inside someone else's cloud. It stores collections as plain text files, in your repo, next to your code. Open source, offline-first, MIT-licensed. That's the whole pitch, and it's working.

The momentum behind Bruno is the kind that suggests Postman is genuinely losing developer goodwill. Account requirements, cloud sync defaults, AI features no one asked for. Bruno took the opposite stance and a lot of engineers said yes.

If you've ever lost a Postman collection to a sync conflict, or had to wrestle with sharing across teams without paying for seats, Bruno feels like the obvious answer. It puts the request files in Git. That's it.

What Bruno actually does

Bruno is a desktop API client. You build collections of requests, organize them in folders, run them against environments, write tests in JavaScript, and chain requests together. Standard fare for the category.

The difference is the storage format. Each request is a .bru file in plain text on your disk. Folders mirror the collection structure. You commit them to Git like any other source code.

That's it. No account. No cloud. No sync conflicts. If your colleague edits a request, you see the diff in the PR. You merge it the same way you merge any other change.

Who Bruno is for

Engineering teams that PR-review their API contracts get the most value. The collection lives in the same repo as the code that calls it. Reviewers can see request changes alongside the implementation that depends on them.

Open-source projects love Bruno. Publishing a collection of working API examples in your README's repo is now trivial. New contributors clone, open Bruno, and immediately have a runnable set of requests.

Solo developers who distrust cloud-locked tooling. Anyone who's been burned by a SaaS company changing terms or pricing on data they consider theirs.

Pricing breakdown

Bruno's core desktop app is free and open source under the MIT license. You can use it forever without paying anyone. The CLI runner is also free.

There's a paid Bruno Cloud product for teams who want hosted secrets management and shared environments. It's optional. The vast majority of users never touch it.

Standout features in Bruno

The Bru DSL is genuinely pleasant. It's a human-readable format that's easy to diff in Git. You can hand-edit a .bru file in any text editor and it makes sense without rendering.

The CLI runner integrates into CI/CD without a special license dance. Run your collection as part of a smoke test. Fail the build if your API contract breaks.

Environment files are also plain text. You can keep public env files in Git and use a .gitignore'd file for secrets. No magic, no vendor-specific encryption layer.

Migration from Postman

Bruno has an importer for Postman collections. It's not 100% lossless. Pre-request scripts and complex test logic sometimes need touch-up. For simple-to-moderate collections, it's a one-click migration.

Honest tradeoffs

Bruno is less polished than Postman for non-technical collaborators. Product managers and customer success folks comfortable in Postman's UI may stumble.

The ecosystem is younger. Fewer plugins, fewer Stack Overflow answers, fewer "we ran into this Bruno gotcha" blog posts. That gap is closing fast.

Some advanced Postman features don't have direct Bruno equivalents yet. Mock servers, monitors, and the in-app collaboration features. If those matter to your workflow, Bruno isn't there yet.

Bruno vs alternatives

Versus Postman, Bruno wins on Git-native workflow, no account requirement, and ideological alignment with how engineers prefer to work. Postman wins on collaboration with non-engineers and ecosystem maturity. See the comparison.

Versus Insomnia, Bruno is more lightweight and Git-friendly. Insomnia is more polished for solo use. Insomnia changed account requirements and lost some users; Bruno picked them up.

Versus Hoppscotch, both are open source and minimal. Bruno's offline-first and Git-native model feels more deliberate. Hoppscotch leans web-first.

For more options, see the best API clients and the Bruno alternatives directory.

Bottom line

Bruno is the right tool for engineering teams who want their API contracts in the same place as their code. It's free, it's good, and it's getting better quickly.

If you can convince your team to commit .bru files to the repo, Bruno will pay back its 30-minute setup cost the first time you do a PR review of an API change. That's the moment you stop missing Postman.

Working with Bruno in a team

Drop the bruno collection into a top-level folder of your application repo. Commit it. Onboard new engineers by saying "open Bruno, point it at the api-collection folder, you're done."

For environment-specific values like base URLs and tokens, use Bruno's environment files. Public ones (like staging URLs) commit to the repo. Secret ones (like personal API tokens) go in a gitignored file.

Pull request reviewers see request changes as plain-text diffs. A change to "POST /users now requires email_verified field" shows up in the .bru file alongside the code that introduced the requirement. The signal is clear.

CLI in CI/CD

The Bruno CLI runner reads .bru files and runs them in sequence. Use it in CI to smoke-test API contracts before deploying. If the test request fails or returns an unexpected status, fail the build.

The runner outputs JUnit XML, which most CI platforms render as test results. You can wire it into GitHub Actions, GitLab CI, or Jenkins without custom glue.

The .bru file format

A .bru file is plain text with a simple block-based syntax. Each request has metadata, the HTTP request itself, headers, and optional pre/post scripts.

You can hand-edit .bru files in any text editor. Quick corrections are faster than launching the GUI for trivial changes. Vim users particularly enjoy this.

The format is stable and human-readable. It's not JSON, not YAML, not Postman's proprietary export. It's its own thing, and it's been the right design choice for what Bruno is trying to be.

Common Bruno questions

Does Bruno support GraphQL? Yes, with first-class support including schema introspection and variables.

Can Bruno replace Postman entirely? For most engineering teams, yes. For teams that lean heavily on Postman's collaboration features (mock servers, monitors, in-app reviews), there's a gap.

How does Bruno handle authentication? OAuth, API keys, basic auth, bearer tokens, NTLM, and AWS Sig v4 are all supported. Refresh-token flows work with a small bit of script.

For more developer tools, browse tools for API development.

Bruno workflow patterns that work

Organize collections by service or domain, not by HTTP verb. "Users API" with all its endpoints together beats separate "GET" and "POST" folders. Reviewing changes is easier; mental load is lower.

Keep environment files small and purposeful. base_url, auth_token, common headers. Bigger environment files become hard to reason about; split if needed.

Use scripts to chain dependent requests. Login first, capture the token, attach it to subsequent requests. Bruno's scripting is JavaScript; the patterns are familiar to most engineers.

Bruno in CI for contract testing

Run a smoke-test collection against staging on every deploy. If a critical request returns the wrong shape or status, fail the deploy.

The CLI runner outputs structured results that GitHub Actions, GitLab CI, and others render as test summaries. The signal is clear when something breaks.

Don't try to replace your unit and integration test suite with Bruno. It's a smoke test layer, not a full test framework. Use it for the "is the deployed API doing the right thing at the surface" check.

Bruno security considerations

Never commit secret tokens to .bru files. Use environment files with secrets gitignored, or pull from secret managers in CI.

Audit dependencies if you use Bruno's scripting heavily. JavaScript runtimes can pull in npm packages; treat the same way you'd treat any code.

Final thoughts on Bruno

Bruno represents a worldview as much as a tool. APIs are code; collections are code; tooling should respect that. Engineers who hold this view feel at home immediately. Engineers who don't may struggle to see the appeal.

The tool keeps improving. The roadmap is community-influenced, the pace is steady, the focus is sharp. It's the kind of project worth supporting through donations or contributions if you use it heavily.

For more developer tools, browse the best developer tools and the broader API testing category.

Quick recap

Bruno fits engineering teams who want their API contracts treated like code. The Git-native model is the headline; the offline-first stance and MIT license are the nuances that close the deal.

The tradeoffs are real but narrowing. Postman's richer collaboration features matter for non-engineering colleagues. Bruno's smaller ecosystem catches up monthly.

For pure engineering use, Bruno is the better default in 2026. The quality of the diff experience alone justifies the switch for most teams.

Browse more options at the best API tools, the broader developer experience category, and Bruno alternatives.