Bruno
Git-friendly API client with local collection storage. The developer's alternative to Postman for version-controlled API workflows.
Overview
Bruno is an open-source API client created in 2023 as a response to the trend of API tools moving to cloud-only storage. Unlike Postman or Insomnia which store collections in proprietary cloud services, Bruno stores API collections as plain text files (Bru format) directly in your Git repository. This makes API collections fully version-controlled, reviewable in pull requests, and portable across teams.
Bruno has gained rapid popularity among developers who want API testing to live alongside their code, not in a separate tool. It supports REST, GraphQL, and SOAP APIs with a clean, fast interface.
What it's used for
Bruno is ideal when:
- Git-native API workflows: Store API collections in version control alongside code.
- Privacy-first: No cloud syncing — all data stays local.
- Team collaboration via Git: Review API changes in PRs just like code changes.
- Fast, lightweight client: No bloat, no account required, no cloud dependencies.
Pros & Cons
Pros
- Git-native collections — version controlled by default
- No cloud or account required
- Fast and lightweight
- Open source and actively developed
- Supports REST, GraphQL, and SOAP
Cons
- Newer tool — smaller community than Postman
- No cloud collaboration features (by design)
- Limited plugin ecosystem
- No built-in test runner for CI (CLI exists but is newer)
- Some advanced Postman features are missing
Platforms & Integrations
Bruno runs on Windows, macOS, and Linux. Collections are stored as local files in a custom Bru format.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full client, all features, community support |
| Bruno Pro | From $19/user (one-time) | Advanced features, collection generators, priority support |
NZ Context
Bruno is gaining popularity among NZ developers who value Git-native workflows. It is frequently discussed in NZ developer communities as the "Postman alternative for Git users." For NZ teams that want API collections in version control, Bruno is the best current option.
Alternatives
- Postman — More features and larger ecosystem, but cloud-dependent.
- Insomnia — Similar lightweight approach with local storage option.
- Hoppscotch — Web-based alternative with local storage support.
When to choose Bruno
A quick decision guide for NZ teams evaluating api testing options.
| Choose Bruno when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team uses Git for everything and wants API collections reviewed in pull requests the same way code is reviewed. | Your QA team is non-technical and relies on Postman's shared workspace UI to collaborate without touching a terminal. | GitHub Actions — run the Bruno CLI as a step in your CI pipeline to catch API regressions on every PR. |
| Privacy and data sovereignty matter — you're testing against APIs that carry sensitive NZ customer data and can't tolerate credentials syncing to a US cloud. | You need deep mock-server capability or contract testing integrated into the same tool — reach for Pact or WireMock instead. | Pact — Bruno covers exploratory and regression testing; Pact owns consumer-driven contract verification between services. |
| You're a small-to-mid NZ dev or QA team that has abandoned Postman after its 2023 cloud-only push and wants a drop-in replacement with zero recurring cost. | Your organisation runs large shared API libraries that dozens of teams consume — Postman's team workspace or Swagger Hub handle that governance layer better today. | k6 — use Bruno for functional API checks, then feed the same endpoints into k6 for load and performance testing. |
Your project is monorepo-based and you want the API collection to live in /tests/api/ next to the source — one repo, one PR, one review. |
You need a browser-based tool your offshore or distributed stakeholders can open without installing anything — Hoppscotch or Postman web suit that better. | Playwright — Bruno validates the API layer; Playwright covers the UI that consumes it. Together they give you full-stack regression coverage. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
/tests/api/. Run bruno run in GitHub Actions on every PR targeting main. The first time a developer merges a change that breaks an existing endpoint and the pipeline catches it before QA even opens Bruno, you've made the argument for the tool — no slide deck needed..env.test, .env.uat) outside the repo or in a secrets manager, and use Bruno's environment variable substitution so no token or NZ tax reference number ever sits in a collection file. Pair with WireMock for mocking the upstream myIR stubs in lower environments so testers never need real credentials to run the suite.The bottom line: Bruno solves a real problem — API collections that drift, can't be reviewed, and live in someone's Postman account. If your team uses Git properly, the migration cost is one afternoon. If your team doesn't use Git properly, fix that first and Bruno comes for free.
Interview questions
Questions you are likely to get if you list Bruno on your CV — with what interviewers are really testing for.
Why would you choose Bruno over Postman, and what trade-offs are you accepting?
What they’re really testing: Whether you understand tool trade-offs or just followed a trend — they want a thinker, not a tool-swapper.
Strong answer covers: Git-native collection storage as the core differentiator; the deliberate loss of cloud collaboration features and why that’s acceptable if your team already uses Git well; the fact that the Bruno CLI is newer than Postman’s Newman so CI maturity is still catching up.
When would you use Bruno for API testing versus a contract testing tool like Pact?
What they’re really testing: Whether you know where Bruno’s responsibility ends and consumer-driven contract testing begins — a common gap in mid-level QA engineers.
Strong answer covers: Bruno owns functional and regression checks on known endpoints; Pact verifies the contract between a consumer and a provider across independent deployments; combining both gives you full API confidence without duplication; in a microservices context (common in NZ fintechs like CloudBooks or ListRight) you need both layers.
You’re joining the QA team at TeleNZ to test a new REST API that handles customer identity and billing data. How would you set up Bruno to keep credentials out of the repository?
What they’re really testing: Practical secrets management — whether you’ve actually used Bruno with real data or just demoed it on a toy API.
Strong answer covers: Store the collection files (.bru) in the repo but keep environment files (.env) out via .gitignore; use Bruno’s environment variable substitution so tokens and base URLs never appear in collection files; pull secrets from a vault or CI secret store at pipeline runtime rather than committing even encrypted values.
Your Bruno tests pass locally but fail in the GitHub Actions pipeline with a 401 Unauthorized error on every request. How do you debug this?
What they’re really testing: CI troubleshooting discipline and whether you understand environment isolation — the most common real-world pain point with Bruno in CI.
Strong answer covers: First confirm the environment file or CI secret is actually being injected — print non-sensitive env vars to the log to verify; check that the Bruno CLI command uses the correct --env flag matching the environment name defined in the collection; rule out token expiry by checking if the same token works in a fresh local run; add a dry-run step that echoes the resolved base URL before the test suite fires.
How would you structure a Bruno collection for a large API with 80+ endpoints across five domains so it stays maintainable as the team grows?
What they’re really testing: Whether you think about collection architecture or just dump requests in a flat folder — they want someone who designs for longevity, not just speed.
Strong answer covers: Mirror the API domain structure in folder hierarchy (e.g. /auth, /payments, /accounts) so new team members can navigate without a map; use folder-level pre-request scripts for shared auth so individual requests don’t duplicate token logic; keep a smoke/ sub-folder per domain with the five most critical checks so CI can run a fast gate (under 2 minutes) before the full suite; tag requests by priority so you can filter to regression-only runs.