Hoppscotch

Last reviewed Aug 26, 2026 · 772 words

The first thing every new Hoppscotch user hits is a request to http://localhost:8000 that fails while the same curl succeeds. Nothing is broken: Hoppscotch runs in your browser, and browsers block cross-origin requests to arbitrary hosts. The fix is the Hoppscotch browser extension or the desktop Agent, which proxy requests outside the browser sandbox. Learn that in minute one and the rest of Hoppscotch is what the 80,100 stars suggest — the fastest way to poke at REST, GraphQL, and WebSocket endpoints without a 500 MB Electron app watching you.

Why the browser-first design is worth the interception dance

Postman and Insomnia are desktop apps that grew accounts, sync, and upsells. Hoppscotch inverted it: the client is a lightweight web app (MIT-licensed, TypeScript) that opens in under a second, and because it is just a page, "install" means bookmarking your own instance. For quick REST calls, GraphQL queries with schema introspection, and live WebSocket or SSE sessions, that speed is the product. The interception dance is the one tax the architecture charges, and the Agent pays it: requests route through a small local binary, so private-network and localhost targets work while the UI stays in the browser.

Self-hosting is a stack, not a container

The catalogue's "multi-container backend stack" con is accurate. A useful instance is three services — the app, the admin dashboard, and the backend API — plus a PostgreSQL database you point at via DATABASE_URL. The project ships an all-in-one image (hoppscotch/hoppscotch) that runs the three services together, each on its own port, with Postgres left to you. Budget the catalogue's 512 MB and give Postgres its own persistent volume and backup routine; collections and team data live there, and the containers themselves are disposable.

One planning note: auth is baked into the deployment. You configure sign-in providers (email or OAuth) through environment settings and manage users from the admin dashboard, so decide day one how your team logs in. Kubernetes manifests exist if that is your shop's default, but for a handful of developers a compose file on any small VM is plenty.

Team workspaces are the actual reason to bother

Solo, hoppscotch.io or the local web app already works, and honestly a git-friendly client like Bruno is a strong solo choice since it keeps collections as plain files in your repo. Self-hosted Hoppscotch earns its keep the moment collections need sharing: team workspaces with role-based access, shared environment variables, and collections that live server-side instead of in one person's export file. For an internal API team this replaces the exact features Postman charges per-seat for, on your hardware, where your API payloads — which are often full of real tokens and sample customer data — never leave the network. That data-locality argument is the strongest one for self-hosting an API client at all.

Know where the enterprise wall is

The core is genuinely open source, but some capabilities sit behind an enterprise license — SSO integration and audit-log style controls are the notable ones at last check. If your requirement list includes "everyone signs in through our identity provider", verify that against the current Hoppscotch docs before committing, and price the enterprise tier against just keeping Postman. For most homelab and small-team uses the open core is complete; it is the compliance-shaped requirements that cross the wall.

Where it fits among the alternatives

Rule of thumb from the dev-tools category: Hoppscotch for interactive, shared, browser-based work; Bruno when collections should be code-reviewed files in the repo; a CLI runner like Hurl when the requests belong in CI rather than in anyone's hands. These compose rather than compete — my own setup uses a self-hosted Hoppscotch for exploration and Hurl files for the regression suite the exploration eventually hardens into.

What I'd do

Solo developer: skip self-hosting, run the web app with the Agent installed, and put anything permanent in Bruno files under git. Team of three or more with internal APIs: self-host — the AIO image plus a managed-or-backed-up Postgres on a small VM, OAuth sign-in configured before you invite anyone, Agent rolled out to every laptop so localhost testing works on day one. Check the enterprise wall against your SSO requirements first. Do that and you have retired a Postman bill, kept request payloads inside your network, and probably improved the speed of the tool people touch 50 times a day.