Skip to content
STACK IT FAST

Hoppscotch

Curated OSSClassicAPI Testing Client6-20 people

Audited from github.com/hoppscotch/hoppscotch

Hoppscotch is an open-source API development ecosystem for testing REST, GraphQL, WebSocket, and MQTT endpoints, shipped as a web app, Tauri desktop and agent apps, browser extensions, and a CLI, with an optional NestJS/Prisma/PostgreSQL backend for teams and sync.

Language
TypeScript
Database
PostgreSQL
Hosting
Caddy
License
MIT
Running for
4 years
Team
6-20 people

Why this architecture

App logic lives in one shared Vue package reused by every client shell, while a native Rust relay and a separate Tauri agent process handle outbound HTTP so desktop and agent users are not limited by browser CORS and sandboxing rules.

Tech stack by layer

11 technologies · audited Sep 17, 2026
Frontend & UI
  • VueVue 3 is the UI framework for the shared app package and every client shell (web, desktop, agent).
  • ViteDev server and production bundler for the selfhost-web, desktop, agent, and admin builds.
  • CodeMirror 6Powers the request/response and script editors (autocomplete, lint, language modes) inside hoppscotch-common.
  • Tailwind CSSUtility CSS for the selfhost-web, agent, desktop, and admin apps.
  • TauriRust-based shell that wraps the shared Vue app into native Desktop and Agent binaries.
Backend & APIs
  • NestJSStructures the hoppscotch-backend REST/GraphQL API into modules, controllers, and services.
  • Apollo Server (GraphQL)Serves the GraphQL API consumed by the web, desktop, and admin clients.
  • PrismaORM and migration tool for the backend Postgres schema; client is generated during postinstall.
  • PassportAuth strategies (GitHub, Google, Microsoft, JWT, local) for backend login and session handling.
  • hoppscotch-relay (Rust)Native curl-based HTTP relay that Desktop and Agent use to send requests outside the browser sandbox.
Data & Persistence
  • PostgreSQLPrimary datastore for the backend, reached through Prisma; the bundled compose service sets DATABASE_URL.
  • RedisBacks GraphQL subscriptions pub/sub via graphql-redis-subscriptions in the NestJS backend.
Infrastructure & Deploy
  • Docker ComposeSelf-host entry point with profiles (default, backend, app, admin, database) built from prod.Dockerfile targets.
  • CaddyServes the static selfhost-web and sh-admin builds in their production Docker images.
  • Nix (devenv)Pins the local development toolchain and services via a devenv-managed Nix shell.
  • NetlifyLegacy static-hosting config for the marketing/web build; the referenced package path predates the current workspace layout.(inferred)

Hoppscotch architecture diagram

Open SVG
Hoppscotch architecture diagramWeb app → Backend (GraphQL); Desktop & Agent → Backend (GraphQL); Admin → Backend (GraphQL); Backend → PostgreSQL (Prisma); Backend → Redis (pub/sub); Desktop & Agent → hoppscotch-relay (send requests); hoppscotch-relay → APIs under test (HTTP); Web app → APIs under test (browser fetch)CLIENTSSERVICESWORKERS & JOBSDATA & STORAGEEXTERNALAdminVueWeb appVue · ViteDesktop & AgentTauriBackendNestJS · Apollo GraphQLhoppscotch-relayRust · curlPostgreSQLPrismaRedisGraphQL subscriptionsAPIs under testHTTP · GraphQL · WSGraphQLGraphQLGraphQLPrismapub/subsend requestsHTTPbrowser fetch
How the main components of Hoppscotch connect, drawn from the audited repository.
Diagram as text
  • Web app (Vue · Vite) → Backend (NestJS · Apollo GraphQL): GraphQL
  • Desktop & Agent (Tauri) → Backend (NestJS · Apollo GraphQL): GraphQL
  • Admin (Vue) → Backend (NestJS · Apollo GraphQL): GraphQL
  • Backend (NestJS · Apollo GraphQL) → PostgreSQL (Prisma): Prisma
  • Backend (NestJS · Apollo GraphQL) → Redis (GraphQL subscriptions): pub/sub
  • Desktop & Agent (Tauri) → hoppscotch-relay (Rust · curl): send requests
  • hoppscotch-relay (Rust · curl) → APIs under test (HTTP · GraphQL · WS): HTTP
  • Web app (Vue · Vite) → APIs under test (HTTP · GraphQL · WS): browser fetch

Key architectural decisions

7 decisions
  1. 01

    One shared Vue package is reused across web, desktop, and agent shells

    packages/hoppscotch-common holds the app logic, routes, and editors; packages/hoppscotch-selfhost-web/package.json and packages/hoppscotch-desktop/package.json both pull it in as "@hoppscotch/common": "workspace:^" instead of forking the UI per client.

  2. 02

    A native Rust relay bypasses the browser for outbound HTTP requests

    packages/hoppscotch-relay/Cargo.toml wraps curl (with NTLM and vendored OpenSSL) so the Desktop and Agent apps can send requests with custom headers, client certificates, and proxies that a browser sandbox would block.

  3. 03

    A separate Tauri agent app runs as a local HTTP proxy for the browser app

    packages/hoppscotch-agent/src-tauri/Cargo.toml builds an axum server plus the relay crate into a standalone system-tray binary, letting the hosted web app delegate privileged requests to a locally running agent process instead of requiring the full desktop app.

  4. 04

    docker-compose.yml exposes profiles instead of one fixed self-host stack

    The file documents default, default-no-db, backend, app, admin, database, just-backend, and deprecated profiles built from prod.Dockerfile targets, so operators choose which services (and whether to use the bundled Postgres) start with "docker compose --profile <name> up".

  5. 05

    GraphQL subscriptions are backed by Redis, not in-process pub/sub

    packages/hoppscotch-backend/package.json depends on graphql-redis-subscriptions alongside @nestjs/graphql and @apollo/server, so realtime GraphQL events can fan out across multiple backend instances rather than staying scoped to one process.

  6. 06

    The self-hosted web build ships its own Go server for serving and verifying assets

    packages/hoppscotch-selfhost-web/webapp-server/go.mod is an independent Go module (klauspost/compress, zeebo/blake3) that compresses and hashes the built web bundle, separate from the Node/Vite toolchain used to build it.

  7. 07

    Local dev environment is pinned with Nix via devenv, not a Node version manager alone

    devenv.nix, devenv.yaml, and devenv.lock at the repo root declare the reproducible shell that CONTRIBUTING.md points to, on top of the pnpm workspace.

How Hoppscotch is built

How Hoppscotch is structured

The repository is a pnpm workspace (pnpm-workspace.yaml: packages/*) that separates a shared client library from several platform-specific shells and one backend service. packages/hoppscotch-common holds the Vue 3 application (routes, editors, request logic) and is consumed as a workspace dependency by packages/hoppscotch-selfhost-web (the self-hosted web build), packages/hoppscotch-desktop (a Tauri app), and indirectly by packages/hoppscotch-agent. packages/hoppscotch-backend is an independent NestJS + Prisma service; packages/hoppscotch-sh-admin is its Vue-based admin dashboard. packages/hoppscotch-cli is a standalone Node CLI for running collections in CI, and packages/hoppscotch-data, packages/hoppscotch-js-sandbox, and packages/codemirror-lang-graphql are smaller shared libraries for data types, script sandboxing, and editor language support respectively. Root-level devenv.nix/devenv.yaml/devenv.lock pin the contributor dev environment.

Frontend

packages/hoppscotch-common/package.json is the largest package in the workspace: Vue 3, Vue Router, CodeMirror 6 (@codemirror/* for the request/script editors), a Monaco editor integration (@guolao/vue-monaco-editor), and the shared @hoppscotch/ui component kit. It depends on three other in-repo packages — @hoppscotch/data, @hoppscotch/js-sandbox, and @hoppscotch/kernel — rather than embedding that logic directly. packages/hoppscotch-selfhost-web builds this shared app for the web with Vite and Tailwind CSS, while packages/hoppscotch-desktop and packages/hoppscotch-agent wrap it (or a subset of platform code) in Tauri, a Rust shell defined in their respective src-tauri/Cargo.toml files. packages/hoppscotch-sh-admin is a separate Vue + Vite app (urql for GraphQL, vue-i18n) for the team/admin dashboard, and depends on hoppscotch-backend as a workspace package for generated GraphQL types.

Backend & APIs

packages/hoppscotch-backend/package.json builds a NestJS application (@nestjs/core, @nestjs/graphql, @apollo/server) exposing a GraphQL API, with REST-style health/auth endpoints via @nestjs/platform-express and @nestjs/terminus. Authentication uses Passport strategies for GitHub, Google, Microsoft, JWT, and local login (passport-github2, passport-google-oauth20, passport-microsoft, passport-jwt). The package's own license field is UNLICENSED, distinct from the repository-wide MIT license on the client packages. Two Rust services extend request execution outside this backend: packages/hoppscotch-relay is a curl-based HTTP relay crate (with NTLM and vendored OpenSSL) used by Desktop and Agent to make requests the browser sandbox would block, and packages/hoppscotch-agent/src-tauri builds that relay plus an axum HTTP server into a standalone local-proxy binary that the hosted web app can talk to.

Data & persistence

PostgreSQL is the backend's primary datastore, managed through Prisma (@prisma/client, prisma, both pinned to 7.9.1 in packages/hoppscotch-backend/package.json); the Prisma client is generated in a postinstall step. docker-compose.yml wires a DATABASE_URL=postgresql://postgres:testpass@hoppscotch-db:5432/hoppscotch environment variable for the bundled Postgres service used in the default self-host profile. Redis is not listed as a standalone infrastructure service in the compose file's shown services, but graphql-redis-subscriptions is a direct backend dependency, indicating GraphQL subscription events are published through Redis rather than kept in a single Node process's memory.

Build, test & deploy

CI is driven from .github/workflows, which the facts file resolves to four workflows: tests.yml, build-hoppscotch-desktop.yml, build-hoppscotch-agent.yml, and release-push-docker.yml. Root package.json scripts (do-lint, do-typecheck, do-test, do-build-prod) are per-package conventions that pnpm -r fans out across every workspace package; hoppscotch-common type-checks with vue-tsc, the backend runs Jest, and hoppscotch-cli builds with tsup and tests with Vitest. husky plus commitlint.config.js enforce commit conventions locally (.husky/pre-commit, .husky/commit-msg). Docker images are built from prod.Dockerfile (root, multi-target for backend/web/admin) as well as package-local Dockerfiles in hoppscotch-backend, hoppscotch-selfhost-web, and hoppscotch-sh-admin, the latter two producing static Caddy-served images.

Self-hosting notes

docker-compose.yml is the documented self-host entry point, offering default (all-in-one plus bundled Postgres and auto-migration), default-no-db (bring your own database), and narrower profiles (backend, app, admin, database, just-backend) so operators avoid port conflicts between overlapping service sets — for example docker compose --profile backend up runs only the API. packages/hoppscotch-selfhost-web/webapp-server/go.mod is a small Go module (klauspost/compress, zeebo/blake3) bundled into the desktop app's prepare-web build step to compress and checksum the static web build it embeds, independent of the Node/Vite toolchain that produces that build.

What to copy (and what not to)

Keeping one shared UI package (hoppscotch-common) and letting each shell (web, desktop, agent) be a thin wrapper around it is a solid pattern for any project targeting multiple runtime targets from one codebase — it avoids re-implementing request logic per platform. The native relay crate plus a dedicated local-agent proxy process is a more specific pattern worth copying only if a web app genuinely needs to escape browser sandboxing (custom TLS, client certs, arbitrary headers); for a project that only ever runs in the browser, that split adds two extra Rust codebases for no benefit. The profile-based docker-compose.yml is a reusable idea for any self-hosted product with optional components (here, an external-vs-bundled database), letting one file serve several deployment shapes instead of maintaining several compose files.

Sources & repo audit

Audited
Sep 17, 2026
Commit
d86e59f
License
MIT

Independent analysis of repository at github.com/hoppscotch/hoppscotch. Spotted an inaccuracy? Use the claim form to request a correction.

Show this stack on your README or website
Tech stack of Hoppscotch
[![Tech stack of Hoppscotch on STACK IT FAST](https://stackitfast.com/badge/hoppscotch.svg)](https://stackitfast.com/project/hoppscotch)

Paste it into your README. It shows your current stack and links to this page.

Use this stack

Scaffold it with your agent

Paste this prompt into Claude Code, Cursor, Windsurf or AGY to start a project with Hoppscotch's architecture.

  1. 1Copy the promptThe full markdown spec, with every layer and decision.
  2. 2Open your AI toolClaude Code, Cursor, Windsurf or Copilot, in a new repo.
  3. 3Paste and scaffoldUse it as the first instruction; review before you ship.
use-this-stack.md · 61 lines · 8.1 KB
# MISSION: Scaffold "Hoppscotch" Production Architecture
You are an expert Senior Staff Software Architect and Full-Stack Engineer. Your mission is to scaffold and implement a production-grade, highly reliable, and modular codebase following the proven architecture of **Hoppscotch**.
---
## 1. PROJECT SPECIFICATIONS & BENCHMARK
- **Reference Architecture**: Hoppscotch
- **What It Does**: Hoppscotch is an open-source API development ecosystem for testing REST, GraphQL, WebSocket, and MQTT endpoints, shipped as a web app, Tauri desktop and agent apps, browser extensions, and a CLI, with an optional NestJS/Prisma/PostgreSQL backend for teams and sync.
- **Domain & Category**: API Testing Client
- **Production Scale**: 6-20 people
- **Development Mode**: CLASSIC
- **Architectural Rationale**: App logic lives in one shared Vue package reused by every client shell, while a native Rust relay and a separate Tauri agent process handle outbound HTTP so desktop and agent users are not limited by browser CORS and sandboxing rules.
- **Live Website Reference**: https://hoppscotch.com
- **Source Repository**: https://github.com/hoppscotch/hoppscotch
---
## 2. PRODUCTION TECH STACK
- **Full Stack Array**: Vue, TypeScript, NestJS, GraphQL, Prisma, PostgreSQL, Redis, Tauri, Rust, Go, Docker
- **Primary Language(s)**: TypeScript, Vue, Rust, JavaScript
- **License of the reference repo**: MIT
- **Frontend**: Vue — Vue 3 is the UI framework for the shared app package and every client shell (web, desktop, agent).; Vite — Dev server and production bundler for the selfhost-web, desktop, agent, and admin builds.; CodeMirror 6 — Powers the request/response and script editors (autocomplete, lint, language modes) inside hoppscotch-common.; Tailwind CSS — Utility CSS for the selfhost-web, agent, desktop, and admin apps.; Tauri — Rust-based shell that wraps the shared Vue app into native Desktop and Agent binaries.
- **Backend & APIs**: NestJS — Structures the hoppscotch-backend REST/GraphQL API into modules, controllers, and services.; Apollo Server (GraphQL) — Serves the GraphQL API consumed by the web, desktop, and admin clients.; Prisma — ORM and migration tool for the backend Postgres schema; client is generated during postinstall.; Passport — Auth strategies (GitHub, Google, Microsoft, JWT, local) for backend login and session handling.; hoppscotch-relay (Rust) — Native curl-based HTTP relay that Desktop and Agent use to send requests outside the browser sandbox.
- **Data & persistence**: PostgreSQL — Primary datastore for the backend, reached through Prisma; the bundled compose service sets DATABASE_URL.; Redis — Backs GraphQL subscriptions pub/sub via graphql-redis-subscriptions in the NestJS backend.
- **Infrastructure & deploy**: Docker Compose — Self-host entry point with profiles (default, backend, app, admin, database) built from prod.Dockerfile targets.; Caddy — Serves the static selfhost-web and sh-admin builds in their production Docker images.; Nix (devenv) — Pins the local development toolchain and services via a devenv-managed Nix shell.; Netlify — Legacy static-hosting config for the marketing/web build; the referenced package path predates the current workspace layout.
---
## 3. KEY ARCHITECTURAL DECISIONS (audited from https://github.com/hoppscotch/hoppscotch @ d86e59f)
1. **One shared Vue package is reused across web, desktop, and agent shells**: packages/hoppscotch-common holds the app logic, routes, and editors; packages/hoppscotch-selfhost-web/package.json and packages/hoppscotch-desktop/package.json both pull it in as "@hoppscotch/common": "workspace:^" instead of forking the UI per client.
2. **A native Rust relay bypasses the browser for outbound HTTP requests**: packages/hoppscotch-relay/Cargo.toml wraps curl (with NTLM and vendored OpenSSL) so the Desktop and Agent apps can send requests with custom headers, client certificates, and proxies that a browser sandbox would block.
3. **A separate Tauri agent app runs as a local HTTP proxy for the browser app**: packages/hoppscotch-agent/src-tauri/Cargo.toml builds an axum server plus the relay crate into a standalone system-tray binary, letting the hosted web app delegate privileged requests to a locally running agent process instead of requiring the full desktop app.
4. **docker-compose.yml exposes profiles instead of one fixed self-host stack**: The file documents default, default-no-db, backend, app, admin, database, just-backend, and deprecated profiles built from prod.Dockerfile targets, so operators choose which services (and whether to use the bundled Postgres) start with "docker compose --profile <name> up".
5. **GraphQL subscriptions are backed by Redis, not in-process pub/sub**: packages/hoppscotch-backend/package.json depends on graphql-redis-subscriptions alongside @nestjs/graphql and @apollo/server, so realtime GraphQL events can fan out across multiple backend instances rather than staying scoped to one process.
6. **The self-hosted web build ships its own Go server for serving and verifying assets**: packages/hoppscotch-selfhost-web/webapp-server/go.mod is an independent Go module (klauspost/compress, zeebo/blake3) that compresses and hashes the built web bundle, separate from the Node/Vite toolchain used to build it.
7. **Local dev environment is pinned with Nix via devenv, not a Node version manager alone**: devenv.nix, devenv.yaml, and devenv.lock at the repo root declare the reproducible shell that CONTRIBUTING.md points to, on top of the pnpm workspace.
---
## 4. NON-NEGOTIABLE ARCHITECTURAL GUARDRAILS
1. **Monorepo & Modular Separation**:
   - Structure as a Turborepo monorepo with strict package boundaries:
     - `apps/web`: Application UI, routing, layouts, and server endpoints.
     - `packages/ui`: Shared design tokens, CSS variables, and Radix UI primitive components.
     - `packages/db`: Database schemas, client singleton, declarative migrations, and seed scripts.
     - `packages/config`: Shared TypeScript, ESLint, and build configurations.
2. **Strict Type Safety & Zero `any` Policy**:
   - Enable `strict: true`, `noImplicitAny: true`, and `strictNullChecks: true`.
   - Validate ALL external inputs, API request bodies, and query parameters with **Zod** schemas before execution.
3. **Frontend & Rendering Guidelines**:
   - Isolate interactive UI state to leaf components. Keep core pages lightweight and performant.
4. **Design System & Aesthetics**:
   - Keep every color, radius, shadow and font in a single token file (CSS variables) and consume tokens everywhere; never hardcode hex values in components.
   - Prefer crisp 1px borders and one subtle shadow scale over blurry default shadows. Pair one sans-serif for body/headings with one monospace for tags, badges, metrics, and code.
5. **Data Layer & Reliability**:
   - Write declarative schema definitions with foreign keys, composite indexes on queried filters, and automated timestamp triggers.
   - Use connection pooling and prepared statements for serverless database execution.
---
## 5. STEP-BY-STEP SCAFFOLDING ROADMAP
- **Phase 1: Workspace & Root Config**: Initialize package manager, monorepo configuration (`turbo.json`, `tsconfig.base.json`, `package.json`).
- **Phase 2: Database Schema & Client**: Set up the data layer (PostgreSQL, Redis): client, connection pool, models, and migration scripts.
- **Phase 3: Design Tokens & UI Primitives**: Build accessible `Button`, `Input`, `Card`, `Badge`, and layout wrappers inside `packages/ui`.
- **Phase 4: Core Application Routes & Handlers**: Implement primary authentication, user session handling, and application routes.
- **Phase 5: Quality Assurance & Build Verification**: Run `tsc --noEmit`, ESLint, Prettier, and smoke test suites to ensure zero compilation or runtime errors.
---
## 6. EXECUTION INSTRUCTIONS
1. Review all specifications, architectural guardrails, and stack choices above.
2. Present the full monorepo directory tree structure.
3. Systematically generate the complete, production-ready codebase according to the 5-phase roadmap above — starting with the root workspace setup, followed by the database schema, UI design system package, and full-stack application routes until the repository is fully scaffolded and ready to run.
Scaffolded something with this prompt?
Would you pick this stack for a api testing client project?

Frequently asked about Hoppscotch

What is Hoppscotch built with?

The client is Vue 3 and TypeScript (packages/hoppscotch-common) shared across a Vite web build, Tauri desktop and agent apps, and a CLI; the backend is a NestJS GraphQL API on Prisma/PostgreSQL with Redis-backed subscriptions.

Does Hoppscotch need a backend?

For sync, teams, and cloud features yes: packages/hoppscotch-backend is a NestJS + Prisma + PostgreSQL service. The client apps can still send API requests without it, since request execution runs locally or through hoppscotch-relay.

Can I self-host Hoppscotch?

Yes. docker-compose.yml at the repo root defines profiles (default, backend, app, admin, database) built from prod.Dockerfile so operators can run the full stack, an external-database setup, or individual services.

Does Hoppscotch have a desktop app?

Yes, packages/hoppscotch-desktop is a Tauri (Rust) app that reuses the shared hoppscotch-common Vue package and bundles the hoppscotch-relay crate for native HTTP requests outside the browser sandbox.

How does Hoppscotch avoid browser CORS limits when sending requests?

Desktop and Agent builds route requests through hoppscotch-relay, a Rust crate built on curl, instead of the browser fetch API; the Agent app additionally runs as a local proxy process that the hosted web app can delegate privileged requests to.

One email a month: new deep dives and stack trends

New source-audited architectures, head-to-head comparisons and the monthly stack report. No spam, unsubscribe anytime.

use-this-stack.md