toolfreebie

Posted on May 3 • Originally published at toolfreebie.com

Postman Alternatives in 2026: Bruno and Hoppscotch — Free, Open-Source API Clients That Don’t Force a Login

#tools #productivity

Why Postman Alternatives Suddenly Matter in 2026

For the better part of a decade, Postman was the default API client. You installed it once, double-clicked the desktop icon, and started firing requests. It was free, it was good, and the company didn’t get in your way.

That’s no longer true. Over the last few years Postman has steadily pushed users toward a cloud-first model: a forced login on launch, collections that sync to Postman’s servers whether you want them to or not, environments that live in the cloud by default, and a free tier that quietly trimmed the number of collection runs, monitors, and shared workspaces. The Scratch Pad — Postman’s local-only mode that never required an account — was deprecated in 2023 and removed not long after. By 2026 the desktop app is essentially a thin shell around the cloud.

For an individual developer, the new shape of Postman has three problems. You can’t open the app without an internet connection on a fresh machine. You can’t put your collections into your project’s Git repo and review changes in pull requests. And you can’t really use it at work without thinking about whether your auth tokens or staging URLs are syncing to a third-party server.

This article is a hands-on walk through the two free, open-source API clients I actually use in 2026: Bruno and Hoppscotch. Both are mature, both are fully Postman-shaped (the cURL-paste, the request tabs, the collections, the environments), and both deliberately fix what Postman broke. Below I cover what each one does best, where they overlap, where they diverge, and how to migrate a real Postman workspace into either of them in about ten minutes.

What I Wanted in a Postman Replacement

Before getting to the tools themselves, here’s the rubric I used. If your priorities differ, your verdict may also differ.

No mandatory account. Open the app, hit the API. That’s it.
Local-first storage. My collections are files on my disk, not records in someone else’s database.
Git-friendly. A request lives in a plain-text file I can diff, review, and commit alongside the code that calls it.
Open-source license. If the company gets weird in 2027, I can fork it.
CLI for CI. I want to run the same collection in a build pipeline as I do at my desk.
Reasonable scripting. Pre-request and post-response hooks for token capture, signature generation, and cleanup.
Imports a Postman v2.1 collection without losing data. Switching costs need to be near zero.

Bruno and Hoppscotch both satisfy the list. They go about it differently — one is a desktop-first text-file engine, the other is a browser-first PWA — and that difference is most of what this article is about.

Bruno: A Git-Native, Local-First API Client

Bruno is a desktop API client that does one thing very deliberately: it stores every request as a plain-text file in a folder on your disk. There is no cloud account. There is no signup screen. There isn’t even a sync option. If you want to share a collection with a teammate, you commit it to your project’s Git repo, and they pull. The whole tool is built around that decision.

It launched in late 2023 explicitly as a reaction to Postman’s cloud direction, and by 2026 it’s the option I reach for first whenever I’m building or testing an API that lives in a code repository.

Installing Bruno

Bruno ships native installers for macOS, Windows, and Linux from the project site. There’s also a Homebrew formula on macOS:

brew install bruno

And a Snap on Linux:

sudo snap install bruno

On first launch Bruno opens to an empty workspace and asks you to either create a new collection or open an existing one. There is no signup screen and no telemetry consent dialog — the binary launches, the window appears, and you can fire your first request inside thirty seconds.

Your First Request

Click New Collection, give it a name, and pick a folder on disk. Bruno will create that folder and put a bruno.json file in it; that file is the collection root. Inside the new collection, click New Request, paste a URL, choose a method, and hit Send. The response panel works exactly the way you’d expect: status code, headers, timing, body with JSON pretty-print.

If you want to skip the form entirely and paste a cURL command, Bruno parses it on import — the same trick Postman has had for years.

The .bru File Format

Here’s where Bruno earns its place on this list. Every request in your collection is a single text file with a .bru extension. Open one in any editor and you’ll see something like this:

meta {
  name: Get current user
  type: http
  seq: 1
}

get {
  url: {{base_url}}/users/me
  body: none
  auth: bearer
}

auth:bearer {
  token: {{api_token}}
}

headers {
  Accept: application/json
}

tests {
  test("status is 200", function() {
    expect(res.getStatus()).to.equal(200);
  });
}

That’s it. No JSON, no UUIDs, no import artifacts. The format is purpose-built to read well in a pull request review. When a teammate adds a new endpoint, the diff in your PR shows up as a new .bru file. When someone changes an auth header, you see exactly which header on which request changed.

Putting your bruno/ folder into the same repo as your application code is the intended workflow. The API client is now part of the codebase — it lives, breathes, and gets reviewed alongside the routes it tests.

Environments and Secrets

Environments in Bruno are also files. They live in an environments/ subfolder of the collection, one .bru file per environment. Switching between local, staging, and production is a single dropdown in the UI, and the file format is just a flat list of variables.

Secrets get a separate treatment. Bruno supports a .env-like override file (.env at the collection root) that’s automatically gitignored. The same variable name in .env wins over the one in the committed environment file, so you can commit API_BASE_URL safely while keeping API_TOKEN off-disk in version control. This is the workflow Postman never quite supported cleanly.

Scripting with JavaScript

Bruno uses a JavaScript scripting model close to Postman’s. Pre-request scripts run before the request fires, post-response scripts run after, and tests run alongside the response. You have access to a req and res object, plus a bru object for variable manipulation:

// Post-response: capture an auth token for later requests
const body = res.getBody();
if (body && body.access_token) {
  bru.setEnvVar("api_token", body.access_token);
}

Pre-request scripts are useful for HMAC signing, dynamic timestamps, or generating idempotency keys. Anything you’d write in Postman’s pre-request tab works here with minor renaming.

The Bruno CLI

The bru CLI runs collections from the terminal. Install it once globally:

npm install -g @usebruno/cli

Then point it at a collection folder and pick an environment:

cd path/to/your/bruno-collection
bru run --env staging

By default it runs every request and reports pass/fail. You can scope to a single folder, output JUnit XML for your CI dashboard, or stop on the first failure. That’s the same shape Newman gives you for Postman, except the input is the same plain-text files you’ve been editing all day.

Where Bruno Falls Short

Bruno is honest about being newer software. The few rough edges I’ve hit:

GraphQL support exists but is less polished than Postman’s. Schema introspection works; the visual query builder is leaner.
WebSocket and Server-Sent Events were added in 2024 and 2025 respectively — they work, but they’re not the headline feature.
Team collaboration features beyond Git are intentionally minimal. There’s a paid Bruno Golden Edition that adds AI-assisted scripting and visual diffing, but the core sync model is and probably will remain “use Git.”

None of these are dealbreakers; they’re just trade-offs that come with the local-first design.

Hoppscotch: A Browser-Based Postman That Loads in 200ms

Hoppscotch takes the opposite approach. Instead of a desktop app with files, it’s a Progressive Web App that runs entirely in your browser. Open hoppscotch.io in any tab and you have a working API client in the time it takes the page to render — no install, no account, no download.

It’s open-source under the MIT license, the source lives on GitHub, and you can self-host it on your own machine or your own infra in under five minutes. The hosted version at hoppscotch.io is free with no rate limits on the core REST/GraphQL/WebSocket clients.

Getting Started in 10 Seconds

Open hoppscotch.io in your browser. The default tab is a REST request panel. Type a URL, pick a method, hit send. Done. That’s the whole onboarding.

If you’d rather keep your data on your own machine, the same UI is available as an Electron desktop app and as a Docker image:

docker run -d -p 3000:3000 hoppscotch/hoppscotch

Visit http://localhost:3000 and you have a private instance with the same UX as the hosted version.

Workspaces, Collections, and Local Storage

Without an account, Hoppscotch keeps your collections, environments, and history in browser local storage. That’s enough for solo development on a single machine. If you want sync across devices or share a collection with a teammate, you can either sign in with a free Hoppscotch account (Google, GitHub, email) or self-host the full backend, which adds a Postgres database and lets you run team workspaces with your own access controls.

The free hosted tier in 2026 includes:

Unlimited personal requests, collections, and environments
One personal workspace
Up to two team members in a free team workspace
The full REST, GraphQL, WebSocket, SSE, Socket.IO, and MQTT clients

For most freelance and side-project work that’s plenty. For a real engineering team, self-hosting the open-source server gives you unlimited everything.

Protocols Beyond REST

Hoppscotch’s standout feature is breadth. The same UI handles:

REST — the default, with full support for headers, body types, auth, and pre-request/test scripts.
GraphQL — schema introspection from a URL, a query editor with autocomplete, and variables/headers panels.
WebSocket — connect, send, receive, with a live event log.
Server-Sent Events — open a connection to an SSE endpoint and stream the events.
Socket.IO — yes, with full Socket.IO protocol support, not just raw WebSocket.
MQTT — connect to a broker, subscribe to topics, publish messages.

Postman has been adding these one by one over the years. Hoppscotch shipped them as a coherent set early, and the experience is consistent across all of them.

Scripting and Tests

Hoppscotch uses a sandboxed JavaScript scripting model, similar in shape to Bruno’s and Postman’s. The objects are slightly different — pw instead of pm or bru — but the patterns translate directly:

// Test script
pw.test("Status is 200", () => {
  pw.expect(pw.response.status).toBe(200);
});

pw.test("Response has a token", () => {
  pw.expect(pw.response.body.token).toBeType("string");
});

// Capture for next request
pw.env.set("auth_token", pw.response.body.token);

Pre-request scripts work the same way — set headers, generate signatures, mutate the request body before sending.

The Hoppscotch CLI

Hoppscotch ships hopp for running collections in CI:

npm install -g @hoppscotch/cli
hopp test path/to/collection.json

It’s lightweight, exits non-zero on failures, and prints a clean per-request summary. Same job as Newman or bru run, with no surprises.

Where Hoppscotch Falls Short

The collection format is JSON, not the file-per-request layout Bruno uses. You can commit the JSON to Git, but the diffs are noisier than a .bru file change.
Browser-based means CORS will catch you off guard the first time you hit a localhost API. The fix is the Hoppscotch browser extension or the desktop app, both of which proxy past CORS.
Heavy team workflows want self-hosting. The hosted free tier is generous for individuals but designed to push real teams toward running their own server.

Bruno vs Hoppscotch: Side by Side

Feature	Bruno	Hoppscotch
Primary form factor	Desktop app	Browser PWA + Electron + self-host
Storage model	Plain text files (.bru)	Browser local storage / Postgres (self-host)
Account required	Never	Optional for sync
License	MIT	MIT (community edition)
Git-native	Yes, by design	Possible (commit JSON), less elegant
Postman v2.1 import	Yes	Yes
cURL paste import	Yes	Yes
REST	Yes	Yes
GraphQL	Yes (basic)	Yes (full introspection)
WebSocket	Yes	Yes
SSE	Yes	Yes
Socket.IO	No	Yes
MQTT	No	Yes
gRPC	Yes	No
CLI runner	`bru`	`hopp`
Scripting	JS (bru.* + req/res)	JS (pw.*)
Self-host	N/A (no server)	Yes (Docker, one container)
Best for	Repo-coupled API testing	Multi-protocol & quick browser use

How to Pick Between Them

Most of the time the choice falls out of two questions:

Is this API client tied to a specific code repository? If yes, pick Bruno. The whole point of Bruno is that the collection lives in your-project/bruno/ next to the code that defines the routes. New endpoints arrive in pull requests as new .bru files. Reviewers can read them. The CI runs them. There is one source of truth, and it’s the same Git repo as the rest of your code.

Is this API client a personal scratch space across many APIs you don’t own? If yes, pick Hoppscotch. You wake up, open a tab, debug a Stripe webhook, debug a Supabase RPC, debug your own staging server, and close the tab. There’s no project to commit to. The browser-resident model is exactly right.

I personally use both. Bruno is what’s installed on my laptop next to the IDE — every active project has a bruno/ folder. Hoppscotch is bookmarked on my browser bar for one-off cURL replacements and for the protocols (Socket.IO, MQTT) Bruno doesn’t cover.

What You Actually Lose vs Postman

The honest part of this article. Postman has invested a decade of engineering hours, and not all of that lands cleanly in either alternative:

Mock servers. Postman lets you spin up a hosted mock from any collection in two clicks. Bruno doesn’t have hosted infrastructure to do this. Hoppscotch has a “REST request inspector” but no full-featured mock. If you depend on Postman mocks, expect to replace them with MockServer, WireMock, or a tiny Express/Hono app you run yourself.
API monitors. Scheduled, hosted runs of a collection. Postman charges for these now anyway, so the right replacement is a GitHub Actions cron job that runs bru run or hopp test. Free, transparent, lives next to your code.
Visualizers. Postman’s HTML/Chart visualizer for response data. Niche feature; both alternatives let you do JSON path inspection and that covers the common cases.
Public API documentation hosting. Postman publishes a public docs page for any collection. Bruno has no equivalent; if you need this, generate OpenAPI from your code and host with Redocly or Scalar instead. Hoppscotch has a community “shared collections” feature but it’s not a docs platform.
Postman Flows / AI features. Postman’s visual chaining of requests and the newer AI assist. Both alternatives have lighter scripting; rebuild flows by writing the chain in JS.

For 90% of REST API work — write request, send, inspect response, scripted assertion, run in CI — neither alternative loses anything compared to Postman. For the cloud-coupled features in the list above, the answer is usually a free standalone tool that does the one thing better, not an all-in-one replacement.

Migrating from Postman in About Ten Minutes

Both Bruno and Hoppscotch import the Postman v2.1 collection JSON natively. Here’s the path I’ve used on a real Postman workspace with about 80 requests across four collections.

Export from Postman. Right-click each collection → Export → choose Collection v2.1. You’ll get a JSON file per collection. Do the same for environments — Postman gives you a per-environment JSON.
Import into Bruno. Open Bruno, click Import Collection, choose Postman Collection, point at the JSON. Bruno converts the JSON into a folder of .bru files and asks where to save it. Pick a folder inside your project repo (your-project/bruno/ is the convention). Repeat for each collection. For environments, click Environments → Import and feed in the Postman environment JSON; Bruno creates a .bru file per environment.
Import into Hoppscotch. Open the Collections panel → kebab menu → Import / Export → Postman Collection. Same drill: pick the JSON, the collection appears in your sidebar. Environments import via the Environments panel.
Audit pre-request and test scripts. The translation isn’t byte-perfect. Postman’s pm.environment.set becomes bru.setEnvVar in Bruno and pw.env.set in Hoppscotch. Search-and-replace in your editor, or run a few requests and fix what breaks.
Move secrets out of the committed environment file. If you used Postman’s “secret” variable type, both alternatives have a similar concept (Bruno’s .env override, Hoppscotch’s secret variables). Move tokens and keys there before you commit the collection.
Wire it into CI. A GitHub Actions step that runs bru run --env staging or hopp test collection.json against your staging deployment after every push gives you Postman monitor-equivalent coverage for $0.

Allow a real day for a large enterprise workspace; ten minutes covers a typical solo project.

Power-User Tips After Six Months on Each

Bruno

Add the Bruno collection folder to your editor workspace. Modern editors render .bru as plain text, and editing a request directly in your IDE is faster than clicking through the GUI for batch changes.
Use the collection-level pre-request script for things like base auth header construction. It runs before every request in the collection, so you don’t repeat yourself.
The seq field in the meta block controls request order in the sidebar — set it deliberately when you import from Postman, otherwise alphabetical ordering can scramble logical groupings.
Bruno’s diff-on-PR story is the actual killer feature. Configure your repo so reviewers must approve changes to bruno/ the same way they approve changes to anything else.

Hoppscotch

Install the Hoppscotch browser extension. It adds a proxy that sidesteps CORS for localhost APIs, which is otherwise the most painful part of using a browser-resident client.
The History panel is a feature, not an afterthought. Every request you fire is logged locally; you can rerun, copy as cURL, or save into a collection without leaving the panel.
Self-host with one Docker command if you’re using Hoppscotch with a team. The community edition is fully featured; you don’t need the hosted enterprise version unless you specifically want SAML or audit logs.
The shortcut bar (?) inside Hoppscotch is dense and worth a one-time read. Most actions have a keyboard shortcut and the app is clearly designed for keyboard-first usage.

Using Bruno or Hoppscotch with OpenClaw

If you’re using OpenClaw to orchestrate AI agents that call APIs, an open-source local-first API client matters more than it does for normal API work. The agent’s tool definitions are usually thin wrappers around HTTP requests, and the way you discover and verify those requests is by hand-firing them in your API client first.

The workflow I’ve settled on:

Spike a new agent integration by adding a Bruno request to the project’s bruno/ folder. Get the request right — auth, headers, body shape — until the response is what the agent will need.
Translate that request into the agent’s tool schema. Because the .bru file is plain text, I can paste the exact URL, headers, and body template into a Claude or Gemini chat and ask it to scaffold the OpenClaw tool definition.
Keep the Bruno request in the repo as a permanent regression check. If the third-party API drifts, the Bruno test fails in CI before the agent silently breaks in production.

For ad-hoc poking around someone else’s API while building an agent — “what does Notion’s search endpoint actually return?” — Hoppscotch in a browser tab is the faster path because there’s no project to set up.

Should You Stay on Postman?

There are a few cases where Postman is still the right answer in 2026:

Your team already pays for the Postman Enterprise tier and uses governance, RBAC, audit logs, and the API governance rules engine. Replacing those with self-built tooling isn’t free.
You depend on Postman Flows for visual workflow building and aren’t ready to express the same logic in code.
Your stakeholders consume your APIs through Postman’s public documentation pages and you’re not in a position to switch documentation tools.

For everyone else — solo developer, small team, indie hacker, agency contractor — the open-source alternatives have caught up to and in places surpassed Postman’s free tier. There’s no longer a reason to accept a forced login and a cloud-by-default model on a tool you use dozens of times a day.

Final Verdict

If you only adopt one, pick the one that matches how you work:

Use Bruno if your API client lives next to a code repository and you want the request collection in Git, reviewable in pull requests, runnable in CI. The .bru file format is the most underrated piece of API tooling shipped in the last three years.
Use Hoppscotch if your API client is a personal scratch pad across many third-party services and you want a tab you can open in any browser on any machine, with optional self-hosting when you’re ready for it.

Both are MIT-licensed, both are mature, both import Postman collections, both run in CI. Whichever you pick, the migration takes a fraction of a day, and the result is an API workflow that doesn’t depend on a vendor’s mood about their free tier.

Get Bruno at usebruno.com, get Hoppscotch at hoppscotch.io. Both are still free, both still respect your local disk, and both will probably outlast Postman’s next pricing change.

Originally published at toolfreebie.com.

DEV Community