Bruno vs Hoppscotch

Last reviewed Aug 26, 2026 · 748 words

Where a collection lives decides this comparison. Bruno writes every request to a .bru text file in a folder you choose, so your API tests are versioned, diffed and reviewed exactly like source code, and there is no server because there is nothing to serve. Hoppscotch keeps collections in a PostgreSQL database behind a web app you run in Docker, so they belong to a workspace and a team rather than a directory. Both replace Postman; they replace it in opposite directions.

One of these is not a self-hosted service

Bruno is a desktop application, Electron-based, for Windows, macOS and Linux. The catalogue lists deployment as bare-metal and source with a 256 MB floor, which is honest: you install it on a laptop, and there is nothing to put on a NAS. Collaboration is git. Two engineers editing one collection resolve it like any merge, and the .bru format is line-oriented enough that conflicts are readable. The bru CLI (npm install -g @usebruno/cli, then bru run --env staging) executes a collection in a pipeline, which is how the tests get into CI without a runner service.

Hoppscotch is the opposite. The public instance at hoppscotch.io is a static web app that fires requests from your browser; the self-hosted Community Edition adds the backend that makes accounts and teams possible. That backend is the catalogue's "multi-container backend stack": frontend, admin dashboard, Node backend and PostgreSQL, wired through one .env file with a long list of OAuth and mail settings. The all-in-one image collapses the first three into one container, but you still run a database, and the 512 MB floor is a starting point. Budget an hour the first time.

The browser's CORS problem, and who has it

Hoppscotch runs in a browser tab, so requests to any API that does not send permissive CORS headers get blocked before they leave. The fixes are the Hoppscotch browser extension, which lifts the restriction, or the proxy setting that relays through the server. A desktop app now removes the issue, but the web edition is what most teams deploy, and every new hire hits the CORS wall once. Bruno never has this problem; it is a native process making native HTTP calls, which is part of why it feels fast against local services on odd ports.

Protocols and the daily grind

Hoppscotch has the wider protocol list: REST, GraphQL with schema introspection, WebSocket, Server-Sent Events, Socket.IO and MQTT, all in the same tabbed interface. Bruno covers REST and GraphQL well, with WebSocket support arriving later and gRPC later still; if your day is mostly pub/sub debugging, Hoppscotch is more comfortable. Both do environments with variables and secrets, both do pre-request and post-response JavaScript, both run assertions. Bruno's declarative assertions block, res.status: eq 200 and friends, reads better in a diff than a script does, and diff readability is Bruno's whole thesis.

Importing from Postman works in both; expect to touch up scripts that used pm.* helpers. The Postman alternatives page covers what survives the move.

What costs money

Both cores are MIT. Bruno funds itself with a paid edition adding features a solo developer rarely needs: extra secret-management integrations, collaboration conveniences, support. Hoppscotch's Community Edition already covers teams; its Enterprise tier adds SSO, audit logs and access controls. Neither locks your data: Bruno's data is text files, and Hoppscotch exports collections as JSON from the app.

Decision table

What I'd do

Bruno, kept in a api-tests/ folder in each service's repository, with bru run in the pipeline. It is the one API client whose "sync" strategy I have never had to explain, because it is git. Deploy Hoppscotch when a team appears that will not open a terminal, or when the protocol list matters, and put it behind the same reverse proxy as the rest of your dev tools. Running both is common and harmless: Bruno for the repo, Hoppscotch for the quick shared poke at a staging endpoint.