Thunder Client vs Hoppscotch: which fits your team's API testing?
Thunder Client suits developers who want to send requests from inside VS Code, with light team needs. Hoppscotch suits teams that want shared workspaces on a server they run themselves. If your renewal, plan limit or data residency question is really about who can see collections and where they sit, the decision turns on four factors: where collections must live, whether teams share workspaces, whether sign-in must go through your identity provider, and whether someone on your staff will operate a server.
Start with storage and sharing. Thunder Client is an editor extension, so its collections sit with the developer's environment and sharing depends on the vendor's team features and plan. Hoppscotch Community Edition keeps team workspaces in a PostgreSQL database that you host, set through DATABASE_URL. Confirm with Thunder Client's current documentation whether its team sharing and storage options meet your residency rules, then check whether the people who need shared access are working in the editor or in a browser. Also confirm whether your sign-in requirement is met: Hoppscotch Community Edition supports Email, GitHub, Google and Microsoft OAuth providers and needs SMTP settings for email, while SAML SSO, OpenID Connect and SCIM provisioning are listed for the Enterprise Edition described in Hoppscotch's self-hosting documentation.
The last factor is operations. A self-hosted Hoppscotch server means someone installs, administers and upgrades it, because Community Edition is updated by the user and the Hoppscotch documentation describes quarterly releases. Ask your platform team who will own the Docker deployment, backups, SMTP and upgrades, and whether that effort is already funded. If nobody can take that on, a single developer working in VS Code may be the better fit, and that choice should be written down and revisited when team size or compliance scope changes.
Which option fits which scenario
This table matches common situations to the better fit between Thunder Client and a self-hosted Hoppscotch instance. Read each row against your own constraints on hosting, sign-in and who will run the server.
| Scenario | Better fit | Reason |
|---|---|---|
| A solo developer working in VS Code | Thunder Client | It runs inside the editor with no server to install, though its free tier and paid plans limit some features. |
| A small team sharing requests | Hoppscotch Community Edition or Bruno | Hoppscotch stores team workspaces in a self-hosted PostgreSQL database, while Bruno keeps collections as files that teams can share through Git. |
| A team needing sign-in through its own identity provider | Hoppscotch Enterprise Edition | Community Edition signs users in through Email, GitHub, Google and Microsoft OAuth, while SAML SSO and SCIM provisioning are listed under Enterprise. Confirm your provider's fit before deciding. |
| A team that must keep collections on its own servers | Self-hosted Hoppscotch | Hoppscotch keeps workspaces and data in a database your team controls, so collections and embedded credentials stay on your infrastructure. |
| A team that wants collections as files in Git | Bruno | Bruno stores collections as files in a local folder, which suits version control and code review. It is an alternative to a self-hosted server rather than a server itself. |
| A team with no one to run a server | Thunder Client or Bruno | Hoppscotch Community Edition is installed, administered and updated by your team, with Docker deployment and a PostgreSQL database to maintain. |
| A team needing CI test runs | Bruno or Hoppscotch CLI | Bruno provides bru run with test reports, and the Hoppscotch CLI runs hopp test with JUnit XML reports. The Hoppscotch CLI is marked alpha, so confirm stability for your pipeline. |
Where Thunder Client and Hoppscotch keep your collections
Thunder Client is an extension inside Visual Studio Code, and collections are tied to the vendor account and the plan the team holds. The plan level decides how many collections you can keep, whether team sharing is available and which import and CLI features you can use, so storage and access cannot be separated from the commercial relationship. Before you standardize on it, confirm with the vendor where collections are kept, whether they sync to vendor servers, how they are encrypted and what happens to them if a seat is removed or a plan is downgraded.
- Account-bound storage: Collections and environments are associated with a vendor account, so access depends on that account remaining active.
- Plan-driven limits: Free-tier caps and paid seat rules determine what a team can keep and share, which can change at renewal.
- Sync behavior: Confirm whether data is stored or synced to vendor infrastructure and in which regions.
- Offboarding: Ask how a departing user's collections are retrieved and whether exports keep environment secrets.
- Credential handling: Ask how stored API keys and tokens are encrypted and who at the vendor can access them.
Confirm current storage, sync and export behavior in writing with the vendor before you decide, because these terms affect where your credentials sit.
Hoppscotch Community Edition keeps team workspaces in a PostgreSQL database. You set the connection through the DATABASE_URL configuration key, so the database runs on infrastructure your organization chooses, such as a cloud account, a data center or an air-gapped network. The install and deployment documentation describes the Docker images and the Helm chart for Kubernetes that host the application. Sign-in uses Email, GitHub, Google or Microsoft OAuth providers that your administrators configure, and email delivery depends on SMTP settings you supply.
- Database ownership: Your team chooses the PostgreSQL version, location, backup schedule and access rules.
- Configuration: The
DATABASE_URLvalue and identity provider settings live in your deployment configuration, so they need the same secret handling as other production configuration. - Sign-in paths: Each enabled provider adds an external identity dependency that your team must monitor.
- Email dependency: SMTP settings control sign-in and invitation mail, so the relay you choose becomes part of the data path.
- Upgrades: Community Edition is installed, administered and updated by your team, with quarterly releases.
Check the prerequisites and install pages before you size the database and confirm the backup and restore plan.
When collections are self-hosted, embedded credentials such as bearer tokens, API keys and basic auth passwords sit on your systems. The vendor no longer holds them, but your team now owns encryption at rest, database access, network exposure, logging, backups and deletion. This is a shift of responsibility, not a reduction of it. Illustrative example: if a backup of the Hoppscotch database is copied to a less protected bucket, the stored credentials are exposed even though the application itself is sound.
- Encryption and backups: Define encryption for the database volume and every backup copy, and test restores.
- Access control: Limit who can query the database and who holds administrator roles in the application.
- Secret hygiene: Prefer environment variables or a secrets manager for credentials used in requests, and avoid storing long-lived production tokens in shared workspaces.
- Network exposure: Place the instance behind your identity and network controls rather than on an open address.
- Retention and deletion: Document how removed users and retired collections are purged from the database and backups.
Ask your security team to review this list against your own control framework before the first team imports collections.
What self-hosting Hoppscotch changes for data control and compliance
Self-hosting moves Hoppscotch collections, workspaces and sign-in data onto infrastructure your team controls, which changes your data location, access and evidence obligations. The cards below cover the decisions that follow from that move and the checks to make before a Thunder Client to Hoppscotch change is approved.
Data location and ownership
A self-hosted Hoppscotch Community Edition stores team workspaces in the PostgreSQL database set through DATABASE_URL. Your team decides which region, cloud account or data center holds that database, along with its backups and replicas. Thunder Client keeps collections in files in your editor and syncs through its own service, so confirm where any embedded credentials, environment values and request history would end up under each option before you move them.
Hosting model choice
Community Edition ships as separate frontend, backend and admin Docker images or as one all-in-one container, and it has a Helm chart guide for Kubernetes. The choice affects who patches each component, how backups run and which network controls you must build. A single container is simpler to run but concentrates responsibility. Map the option your platform team already operates to your change control process.
Sign-in and identity providers
Community Edition signs users in through Email, GitHub, Google or Microsoft OAuth providers that the administrator configures. Each provider you enable becomes part of your access control chain, so decide which identities may sign in and who removes access when someone leaves. Email sign-in depends on SMTP settings, which means a mail relay must be configured, secured and monitored before anyone can use that method.
Upgrades and supported updates
Community Edition is installed, administered and updated by your team, and it receives quarterly releases with community forum support. Enterprise Edition adds SAML-based SSO, OpenID Connect, priority support and guaranteed quarterly updates, and it requires a license key. Compliance programs often expect patching and vulnerability handling to be documented, so decide whether your team can meet that cadence alone or whether a support agreement is required.
Audit trails and access logs
Community Edition does not list activity or audit logs among its features. Enterprise Edition includes activity and audit logs, SCIM user and group provisioning and user groups. If your controls require records of who changed a shared collection, confirm with Hoppscotch which edition provides that evidence and how long logs are kept before you rely on it in an assessment.
Compliance obligations and evidence
Self-hosting gives you control over where data sits, but it does not make the platform compliant. DeployOpen prepares configurations, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any report or certification. Your team must confirm which regulations, contracts and internal policies apply to API collections that may hold credentials and test data, and what your auditor will accept as evidence.
What running a Hoppscotch server involves day to day
Running a self-hosted Hoppscotch instance is an operating commitment, not a one-time install. The Community Edition is installed, administered and updated by your team, so the first decision is who owns the container images, the PostgreSQL database set through DATABASE_URL, the sign-in providers and the SMTP settings. Build capacity matters only at build time: the documentation for the build step calls for 4 CPU cores and 4 GB of RAM, while hosting the built output needs as little as 1 CPU core and 2 GB of RAM. Confirm those figures against the install and build guide and size the hosting tier for your expected number of concurrent users, which the documentation does not quantify for you.
PostgreSQL is where your team's workspaces, collections and environments live, so it needs the same backup, restore testing and patching discipline as any other system of record. Ask your database team to define backup frequency, retention and a tested restore procedure before the first team imports Postman collections. Upgrades are the recurring task. Community Edition releases arrive quarterly and each one must be pulled, deployed and checked by your team. The version to check against today is 2026.9.0, released on September 30, 2026, and the deploy and upgrade guide describes the steps. Keep a staging copy of the database so you can test each upgrade before it reaches users.
If your organization needs SAML single sign-on, SCIM provisioning or audit logs, the Community Edition does not provide them. Those controls belong to the Enterprise Edition, which requires a license key and is priced separately, so the license is a recurring cost to include in any comparison. Before you commit, confirm with Hoppscotch which edition covers each control your identity and audit policies require, and whether the Community Edition's built-in sign-in options satisfy your access rules. Budget internal time for these tasks: monitoring the instance, rotating secrets, reviewing user access and answering the forum questions that replace vendor support.
What each option costs over time
What does Thunder Client cost per seat over time?
Thunder Client charges per seat on paid plans, and the free tier caps use, so the recurring cost scales with the number of people who need paid features. Confirm current Starter, Business and Enterprise prices directly with the vendor, because plan tiers and seat rules can change. Ask whether imports, team sharing and CLI runs sit behind paid plans, since those features drive the tier your team needs. Budget for a recurring per-seat line and check whether annual billing changes the rate.
What does Hoppscotch Cloud cost for each user?
Hoppscotch publishes its cloud pricing on its pricing page: Cloud Free at $0, Business at $6 per user per month and Enterprise at $11 per user per month, billed annually. These are recurring per-user charges that grow with headcount. The Cloud tiers are a separate choice from self-hosting, so compare them only if you would accept hosted storage of your collections. Confirm the current figures on the pricing page before you finalize a budget, since published rates can change.
Is the Hoppscotch Community Edition free to run?
The Community Edition has no licence fee. Hoppscotch's self-hosting documentation describes it as free, open source and usable for personal and commercial projects, under the MIT License. Your real costs are the infrastructure, database, email service and the staff time to install, upgrade and back it up. Those costs recur, and they are the main line item to model. The Enterprise Edition adds a licence key and is priced separately, so ask for it in writing if you need SSO provisioning or audit logs.
What server infrastructure does a self-hosted Hoppscotch instance need?
Hoppscotch's prerequisites list 4 CPU cores and 4 GB of RAM to generate the build image, and as little as 1 CPU core and 2 GB of RAM to host the output. The build machine is needed for installs and upgrades, so it is a short-term resource, while the hosting footprint recurs. Cloud compute, storage and backups are billed by your provider, and they scale with users and collection size. Ask your hosting team to price a small and a highly available layout, and confirm sizing against the current prerequisites page.
What do PostgreSQL and SMTP add to the running cost?
Community Edition stores data in PostgreSQL, set through the DATABASE_URL configuration key, and needs SMTP settings for email sign-in and notifications. If you already run a managed or internal PostgreSQL service, the added cost is storage, backups and a share of administration. If you do not, you add a recurring database line. SMTP is usually a small recurring fee from an existing mail provider, or no added cost if your mail relay is internal. Confirm the database version and email settings against the install documentation before sizing.
How much staff time do upgrades and backups take?
This is the largest recurring cost that teams often miss. Community Edition is installed, administered and updated by your own team, with quarterly releases and community forum support, so each upgrade consumes engineering time. Backups of the PostgreSQL database and the configuration must be tested, not only scheduled. Hoppscotch's own release cadence is calendar-versioned, so plan a recurring upgrade window. Ask who owns the on-call rota, how long a rollback takes, and whether a retainer covers upgrades and testing.
What does migrating collections cost in effort?
Migration is mostly a one-time cost. Hoppscotch's importer accepts Postman and Insomnia collections and environments, plus OpenAPI, with a 50 MB import limit on self-hosted editions. The effort depends on how many collections you have, how many scripts and variables must be rewritten, and how many CI pipelines call the Thunder Client CLI. Fewer, cleaner collections cost less to move. Ask for a sample migration of one representative collection before committing to the full set.
What should I ask for in a quote for a self-hosted Hoppscotch deployment?
Ask for a written scope that separates one-time work from recurring work. One-time items include installation, sign-in configuration with the chosen OAuth providers, SMTP setup, migration of collections and a test run. Recurring items include infrastructure, database and mail costs, upgrades, backups, monitoring and support. Ask which licence tier you need, whether the Enterprise Edition is required for SAML or SCIM, and how upgrades and backup restores are tested. DeployOpen fixes scope and deliverables in writing before work starts, and ongoing support is offered as a retainer.
How a move from Thunder Client to Hoppscotch works
The sequence takes a team from its Thunder Client collections to a self-hosted Hoppscotch workspace that it controls, with each step ending in a check that the old requests still run. The order matters because imports, sign-in and CI changes depend on decisions made at the start.
Inventory collections, environments and secrets
The team lead or a senior developer lists every Thunder Client collection, environment and variable set, and notes which ones are shared, which hold credentials and which are used by CI jobs or scripts. Record each item in a simple table with its owner. The step is done when every collection has an owner and a decision on whether it moves, is rebuilt or is retired. Credentials should be flagged now so they can be rotated or moved to a secrets store rather than copied into the new workspace.
Export collections and environments
Each collection is exported from Thunder Client to a file, and the environments are saved alongside them. Thunder Client's export output is not guaranteed to match a format Hoppscotch reads, so the team should confirm the export format in its current version before relying on it. Keep the exported files in a version-controlled location that the platform team can access. The step is done when every inventoried collection has a file and the file count matches the inventory.
Convert or import into Hoppscotch
Import the files through Hoppscotch's importer. The importer accepts collections and environments from Postman and Insomnia, and collections from OpenAPI, so a Thunder Client export may need conversion to one of these formats first, or the team can rebuild the request from an OpenAPI description where one exists. Self-hosted editions limit each import to 50 MB, so split very large collections before importing. The step is done when each collection opens in Hoppscotch with the expected folder structure, request count and sample responses.
Deploy and configure the self-hosted server
The platform or DevOps engineer deploys Hoppscotch Community Edition using the Docker images or the Helm chart for Kubernetes, sets the PostgreSQL connection through DATABASE_URL, and configures at least one sign-in provider. Email sign-in requires SMTP settings. The administrator, who keeps the install, upgrades and backups in-house, should also decide how the instance is reached from developer machines. The step is done when a test user can sign in, create a workspace and see a restored database after a restart.
Re-create scripts and environment variables
Pre-request and test scripts written for Thunder Client are reviewed and rewritten where Hoppscotch uses different syntax or APIs. Environment variables are recreated in Hoppscotch environments, with credentials referenced from the team's secrets store where possible. Each script is run against a non-production API and its results compared with the Thunder Client output. The step is done when every script passes the same checks it passed before, and any differences are documented.
Move CI runs to hopp test
Any pipeline that runs Thunder Client collections is changed to use the Hoppscotch CLI, installed from npm as @hoppscotch/cli. The CLI is labeled alpha, so the team should pin a version and confirm the required Node.js version, which is 22 or later for current releases. Use hopp test with JUnit XML output so the existing pipeline can read the results. The step is done when a pipeline run completes on the new CLI and its JUnit report is published where the team reads test results.
Validate and retire the Thunder Client workspace
The team runs both tools side by side for a period it sets, comparing responses for the critical requests and confirming that developers can find, share and update collections in Hoppscotch. Teams that need sign-in controls beyond the Community Edition should confirm with Hoppscotch which Enterprise Edition features they require before retiring the old setup. Once the owner signs off, the Thunder Client collections are archived and access is removed. The step is done when a written sign-off confirms that all in-scope collections, scripts and CI runs work in Hoppscotch.
What buyers ask before choosing Hoppscotch over Thunder Client
How much effort does a self-hosted Hoppscotch server take to run?
Running Hoppscotch Community Edition is an ongoing operations task, not a one-time install. The Community Edition is installed, administered and updated by your team, and the project publishes quarterly releases with community forum support. The effort scales with how many people use the instance, how often you upgrade, and how much monitoring and backup discipline you apply. Before committing, ask your platform team to estimate the upgrade cadence and the on-call coverage they can give to a shared internal tool.
Can our team run Hoppscotch without outside help?
Yes, if your team already runs containers, a PostgreSQL database and an identity provider. The Community Edition is administered by the user, so no vendor staff are required to keep it running. Teams without that experience usually need either time to learn the stack or a fixed-scope implementation engagement. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer. Your internal skills, not the software, determine whether outside help is needed.
What does a self-hosted Hoppscotch server need from our infrastructure?
The server needs a few defined components, each owned by someone on your side:
- Docker containers, either separate frontend, backend and admin images or a single all-in-one container, with a Helm chart guide available for Kubernetes.
- A PostgreSQL database connected through the DATABASE_URL setting.
- OAuth providers for Email, GitHub, Google or Microsoft, configured by an administrator.
- SMTP settings so the instance can send email.
- A backup routine covering the database and configuration.
For the build step, the documentation lists 4 CPU cores and 4 GB of RAM, and as little as 1 CPU core and 2 GB of RAM to host the output. Confirm these against the current prerequisites page before sizing hardware.
How long does a migration from Thunder Client to Hoppscotch take?
The duration depends on the number of collections, environments, scripts and test suites, and on how many people must be trained and how many CI jobs must be rewired. Hoppscotch's importer accepts Postman and Insomnia collections and environments and OpenAPI collections, but it does not import Thunder Client files directly, so an export step is needed. Your timeline also depends on how much your team wants to validate after import. Ask any provider for a written scope that lists collection count, script types and CI jobs before accepting a timeline.
Do Thunder Client collections import into Hoppscotch directly?
Not as a native Thunder Client file. Hoppscotch's importer accepts collections and environments from Postman and Insomnia, and collections from OpenAPI. Teams usually export their requests in a format the importer accepts, then check URLs, variables, authentication and scripts after import. The importer size limit is 50 MB on self-hosted editions, which matters only for very large collections. Confirm the exact export path from your current Thunder Client version before planning the work.
Is the Hoppscotch CLI ready for CI pipelines?
The CLI can run collections in CI, but it is documented as alpha, so treat it as a component to pilot before you depend on it. The package is installed from npm as @hoppscotch/cli, runs hopp test against a file or a self-hosted instance, and can write JUnit XML reports that most CI systems read. Current versions need Node.js 22 or later. Pilot one pipeline, pin the CLI version, and check the report format against your CI tooling before moving every job.
Does Hoppscotch Community Edition include team sign-in and audit logs?
Community Edition supports sign-in through Email, GitHub, Google and Microsoft OAuth providers, which covers many internal setups. Features such as SAML-based SSO, SCIM user provisioning and activity and audit logs are part of the Enterprise Edition, which requires a license key. If your compliance or identity team needs those controls, confirm with Hoppscotch which edition meets the requirement before you design around the Community Edition.
When a fixed-scope engagement makes sense
A fixed-scope engagement makes sense when a team has decided to leave Thunder Client for Hoppscotch but lacks the time or in-house skills to run the change safely. The work splits into four parts: moving collections and environments, building the self-hosted server, connecting sign-in, and hardening and documenting the result. Hoppscotch Community Edition is installed and updated by the customer, uses Docker containers, stores team data in PostgreSQL through DATABASE_URL, and needs SMTP settings for email, so each part has its own owners, credentials and failure modes. Before work starts, confirm who owns the database backups, the SMTP relay, the OAuth applications for Email, GitHub, Google or Microsoft, and the Kubernetes cluster if the team uses the Helm chart.
A written scope should name each deliverable and the environment it lands in: the hosting account or data center, the container images and versions to deploy, the sign-in providers enabled, the import checks run against Postman or OpenAPI sources (noting the 50 MB limit on self-hosted editions), and the hopp test jobs that replace any Thunder Client CLI runs, with JUnit XML output for the CI system. It should also state acceptance criteria, such as which collections must import cleanly and who signs off, and what happens to the Thunder Client exports afterward. Ask for the handover documents, the backup and restore procedure, and the upgrade process, because Community Edition updates are the customer's responsibility.
Ongoing support is a retainer, not part of the initial scope. Once the server is live, the team still needs someone to apply quarterly releases, review the Hoppscotch release notes, rotate secrets and keep the backup tests passing. Ask for the response expectations in writing and decide who inside the organization approves changes. If your team later needs Enterprise Edition features such as SAML SSO or SCIM, confirm the license terms with Hoppscotch first, since those features are not part of Community Edition. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and the scope should say exactly which of those activities are included.
How DeployOpen works on this
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure. For Thunder Client vs Hoppscotch, we start from how your team shares collections, signs in and runs tests, then decide with you whether a self-hosted Hoppscotch instance fits the work.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists which collections, workspaces and environments move to a self-hosted Hoppscotch instance.
- We record sign-in methods, SMTP settings, import sources and CI runs that the scope must cover.
How we build
- We plan the Community Edition deployment as Docker containers or a Helm chart, inside your own environment.
- We configure PostgreSQL through DATABASE_URL, OAuth providers and SMTP for the users you approve.
- We test imports from Postman, Insomnia and OpenAPI, then check requests and environment variables against your collections.
How we hand over
- You receive configuration documentation, runbooks for upgrades and backups, and a list of known gaps.
- We document how the hopp test CLI runs in your pipeline, including JUnit XML reporting, and flag its alpha status.
- We confirm with you which features, such as SSO or audit logs, need the Enterprise Edition before handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow the release cadence you agree, with testing before each change reaches your team.
- Security testing of the deployed instance can be scoped as a separate engagement if your policy requires it.
