When a Thunder Client alternative makes sense and when Bruno fits
Start with the trigger. A free-tier cap, a plan change or a policy that keeps API collections off vendor clouds each points to a different client, so name your reason before comparing features. Thunder Client fits editor-first work: developers who build and send requests inside Visual Studio Code, keep collections for their own use, and stay within the free plan's limits as individuals. Bruno fits when collections belong in source control, when people need to work offline, or when the same requests must run in a pipeline through bru run. Bruno keeps each collection as plain files in a folder, so the collection travels with the code it tests.
Three questions decide the rest. First, import and CLI needs: check whether your existing collections export as Postman Collection v2 or v2.1 JSON, which Bruno imports, and list which scripts or CI jobs call the Thunder Client command line today, since those will need rewriting for bru run. Second, team size: count the people who edit the same requests and whether they need shared sign-in or a single shared workspace, because Bruno's free edition limits workspaces and its paid editions add single sign-on and provisioning. Third, Git review: if request changes should go through pull requests, confirm which Git actions your edition exposes in the app, since push, branch operations and merge conflict resolution are paid features on Bruno's pricing page, while Git itself works outside the app on every edition. Run a trial export of one representative collection before you decide.
Which client fits which team scenario
This table matches common team situations to the client that fits them better, based on where Bruno keeps collections, its Git workflow, CI runs and paid tiers. Read each row against your own constraints, then confirm plan limits and data storage with Thunder Client before you decide.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Solo developer who wants to stay inside VS Code | Thunder Client | Choose it if you want requests inside the editor and your use fits the free tier's collection limit. |
| Team that reviews API requests in pull requests | Bruno | Collections are plain files in a folder, so diffs and reviews work in Git. Push and branch actions in Bruno's Git UI are paid features. |
| Team that needs CI runs from the command line | Bruno | The bru CLI runs collections with test reports. Confirm your Thunder Client plan covers its CLI before relying on it in pipelines. |
| Organization that must keep credentials off third-party clouds | Bruno | Offline-only with no cloud sync, so collections and embedded credentials stay in a folder you control. Confirm where Thunder Client stores data on your plan. |
| Team that requires SAML single sign-on and SCIM provisioning | Depends on tier | Bruno covers these in its paid editions through license keys. Check Thunder Client's Business and Enterprise plan terms for the same controls. |
| Team migrating existing Postman collections | Bruno | Bruno imports Postman v2 and v2.1 JSON. Scripts using postman-collection or newman need manual rework after import. |
| Team with many separate workspaces | Confirm first | Bruno's Open Source edition allows 2 workspaces, so larger setups may need a paid edition. Confirm Thunder Client's workspace limits on your plan. |
| Team that starts from OpenAPI specifications | Bruno | The bru import command creates collections from OpenAPI. The Open Source edition limits OpenAPI syncs to 5 per month. |
Where Thunder Client and Bruno keep collections
Bruno stores each collection as files in a folder on the user's filesystem, so the folder itself becomes the shared source of truth. Teams can put that folder under Git, review request changes in pull requests and roll back a bad edit like any other code. The Bruno README states that Bruno is offline-only and that the project has no plans to add cloud sync, so collaboration happens through the version control system the team already runs. Collections, environment files and the credentials referenced in them stay where the team puts the repository.
Thunder Client organizes requests into collections and workspaces inside the Visual Studio Code extension, and the storage model determines what a reader is actually adopting. Before comparing features, confirm with the vendor whether collections are kept only in local extension storage, synced to vendor-hosted infrastructure, or both. Also ask whether environment variables holding tokens are encrypted, where that encryption key is managed, how a team workspace is shared, and which plan includes sharing. If data reaches vendor infrastructure, embedded credentials and request history sit outside your control, and offboarding depends on the vendor's export and deletion process.
Turn these questions into a short check before any migration. Ask for a written description of the data flow, then create a sample collection that uses a dummy token and see whether that token appears in any vendor-side location. Confirm that you can export collections in a format Bruno can import, which the Bruno migration guide covers for Postman collections. Finally, decide how a departing developer's copy is removed. With Bruno, that means deleting a local folder and checking the Git remote. With Thunder Client, the answer depends on the vendor's answers above.
Capabilities compared: storage, scripting, imports and CI
This table compares where collections live, how Git fits in, which imports and scripts carry over, and how runs reach CI for Thunder Client and Bruno. Where a Thunder Client cell says to confirm, check its current pricing and feature pages before you decide, because plan limits change. Treat every confirm item as an open question, not as parity.
| Capability | Thunder Client | Bruno |
|---|---|---|
| Collection storage | Confirm on the current Thunder Client pricing page whether collections sync to its cloud and how the free tier caps collections | Collections are plain files in a local folder. The README states Bruno is offline-only with no plans for cloud sync |
| Git workflow | Confirm how Thunder Client collections are versioned and whether team sharing depends on its cloud or a repository export | Store the folder in any Git repository. Clone, diff, pull and commit are in the Open Source edition, while push, branch operations and merge conflict resolution in the Git UI are paid |
| Postman import | Confirm which Postman formats and which volumes of collections the free and paid plans import | Imports Postman collections in Collection v2 or v2.1 JSON. Bulk import of a full Postman data dump is in the Ultimate edition |
| OpenAPI import | Confirm whether OpenAPI import is available on your plan | The bru import command creates collections from OpenAPI. Open Source users have a limit of 5 OpenAPI syncs per month |
| Scripting compatibility | Confirm how Thunder Client scripts are stored and whether they can be exported with collections | Translates common pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response calls on import. Postman-specific packages such as postman-collection and newman are flagged as unsupported |
| CLI and CI runs | Confirm whether the Thunder Client CLI and its CI support are available on your plan, and what it outputs | bru run executes collections from the command line and produces test reports for pipelines |
| Team sign-in and audit | Confirm whether SSO, provisioning and audit logs are included or paid, and on which tier | Paid editions add SAML single sign-on and SCIM provisioning with license keys. Open Source needs no license management, and audit logging is not listed as a feature |
| Price per seat | Confirm the current per-seat price and free tier limits on the Thunder Client pricing page | Open Source is $0. Pro is $6 and Ultimate is $11 per user per month, billed annually, per Bruno's pricing page |
Data location, licensing and what the editions change
Where collections live, under what license they ship, and which features sit behind paid editions decide how a security or compliance review of an API client goes. The cards below cover each of these points for Bruno and the terms you must confirm for Thunder Client before you commit.
Collections stay on your filesystem
Bruno keeps collections in a folder on the user's own disk, and its README states it is offline-only with no plans to add cloud sync. Request headers, environment files and any embedded credentials therefore sit where your endpoint and backup controls already apply. Check who can read that folder, whether it is excluded from synced personal cloud drives, and how credentials are kept out of committed files.
MIT license with 2022 notice
Bruno's source is licensed under the MIT License, and the license file carries a 2022 copyright notice for Anoop M D, Anusree P S and contributors. For a review file, this means the license terms are public and can be read without a contract. Have legal counsel confirm that the MIT terms fit your internal software policy, and record the version you deploy.
Open source use without license keys
Bruno's documentation states that open-source users need no license management. Nothing in the free edition depends on a license server or a vendor portal being reachable. Cost comes from people and time, not seats, but the free edition is limited to 2 workspaces. Confirm workspace needs before rollout, since that limit shapes how teams split their collections.
Pro and Ultimate add identity controls
The paid editions use license keys managed in a license portal, and that portal also covers SAML single sign-on and SCIM provisioning. Those features matter when an identity team must enforce sign-in and offboarding for every user. Ask Bruno which edition includes which control, and whether the license portal is a new dependency your risk register must cover.
Thunder Client data handling terms
Thunder Client is a commercial Visual Studio Code extension with a limited free tier and paid plans, and its data handling depends on the plan and the vendor's terms. Before comparing, obtain Thunder Client's current terms and document where collections, environments and any sync data are stored, who can access them, and how deletion works. Compare those answers with the Bruno facts above rather than assuming either side.
Paid Git features and what remains
Bruno's pricing page places Git push, branch operations, remote connections and merge conflict resolution in the app's Git UI behind paid editions. Clone, initialize, diffs, pull and commit remain in the free edition, and Git itself works outside the app on any edition. Teams that rely on in-app branching should price the paid seat, while teams comfortable with the command line can keep the free edition.
Scripting, imports and CI runs by workflow
Most developers who use Thunder Client build and send requests from inside Visual Studio Code. Bruno works differently because it is a separate desktop application that opens a folder on disk. Requests are written as plain files, so the editor-side habit of saving a request and sending it again carries over, but the request lives in a folder you open in Bruno rather than in the extension's storage. Bruno imports Postman collections exported in Collection v2 or v2.1 JSON format, and it can create collections from OpenAPI specifications.
- Postman import: Bruno accepts Collection v2 and v2.1 JSON, so export from your source tool in one of those formats and open the file from Bruno's import menu.
- OpenAPI import: Bruno's bru import command and the app can generate requests from an OpenAPI document, which suits teams that already maintain specs.
- Script translation: Bruno translates common Postman APIs such as pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response during import.
- Unsupported packages: Postman-specific packages such as postman-collection and newman are flagged as unsupported, so scripts that call them need manual rewrites.
- Thunder Client side: Confirm on your plan whether Thunder Client's export and import options are included, because the free tier limits collections and imports are paid features.
Before you rely on imported scripts, run each request once in Bruno and compare responses against Thunder Client for the same environment.
Bruno stores each collection as files in a local folder, so review happens in the same tools your engineers already use for code. Changes to requests, assertions and environment files appear as ordinary diffs. Bruno's README states that teams can collaborate with Git or any other version control. Thunder Client's collaboration model depends on its own team and workspace features, so the review path for a shared collection is different and should be mapped before you switch.
- Plain-text diffs: Request files and collection settings can be reviewed line by line in a pull request.
- OpenCollection option: Starting with Bruno 3.0.0, requests can be saved as OpenCollection YAML, which some teams find easier to read in review than the .bru format.
- Git UI limits: The Open Source edition covers clone, initialize, diffs, pull and commit in the app, while push, branch operations, remote connections and merge conflict resolution are paid features. Git itself still works outside the app on any edition.
- Secrets in files: Keep credentials out of committed environment files and confirm how your team handles them before the first commit.
- Thunder Client side: Confirm how your current team shares collections and whether any review history must be preserved during the move.
Check that the Git workflow your team needs, including push and branch operations, works on the edition you choose before you move shared collections.
Teams that run API tests in a pipeline need a command-line runner, and Bruno provides one through the bru CLI. The bru run command executes collections and produces test reports, which lets the same requests you use in development run as a build step. Moving CI runs means replacing the Thunder Client CLI invocation with bru run and checking that environments and secrets are supplied the same way as before.
- Command: Use bru run against the collection folder and select the environment the pipeline needs, following the Bruno CLI documentation.
- Test reports: The CLI produces test reports that your pipeline can publish, so compare the report format with what your current job consumes.
- Secrets injection: Pass credentials through your CI secret store rather than committed environment files.
- Script behavior: Scripts that rely on translated Postman APIs should be rerun in CI, since behavior in the pipeline is what matters for gating.
- Thunder Client side: Confirm whether CLI access is included on your plan, because the Thunder Client CLI is tied to paid tiers and your current job depends on that entitlement.
Run the migrated collection in a non-production pipeline before you remove the existing Thunder Client job.
What each option costs over time, by component
Licence fees are only one line in the total. The cards below separate what you pay a vendor, what recurs each year, and what you spend internally once, so you can compare Thunder Client seats with Bruno editions and your own effort on a like-for-like basis.
Bruno Open Source edition
The Open Source edition is listed at $0 and covers the desktop client with clone, initialize, diffs, pull and commit in the Git UI. It is limited to 2 workspaces and 5 OpenAPI syncs per month. Check whether those limits fit how many separate API projects your teams keep, since a team with more workspaces will hit the cap before any licence cost arises. Git itself works outside the app on any edition.
Bruno Pro and Ultimate seats
Pro is listed at $6 per user per month and Ultimate at $11 per user per month, both billed annually. These are recurring per-seat costs, so the total scales with headcount. Pro adds Git push, branch operations, remote connections and merge conflict resolution in the app. Ultimate adds bulk import of a full Postman data dump. Ask whether a seat count is a minimum, how the licence key is issued and renewed, and whether SAML single sign-on and SCIM are included in your edition.
Thunder Client seats
Thunder Client sells Starter, Business and Enterprise plans, but no prices were supplied for this page, so take current per-seat figures from the vendor in writing. Compare them against your Thunder Client seat count, not your developer count, because the free tier caps collections and imports and CLI use sits behind paid plans. Ask which features each plan includes, whether renewal rates change, and what happens to team collections if you stop paying.
Internal setup and migration effort
This is a one-time cost paid in engineer hours, not licences. It covers exporting collections, importing them into Bruno, and rewriting scripts and environment variables that do not translate cleanly. Illustratively, a team with a small collection set spends far less time here than one with long test suites. Estimate it from your own collection count and script complexity, and agree on who owns the cutover before work starts.
CI wiring and script upkeep
Moving CI runs from the Thunder Client CLI to bru run is a one-time change to pipelines, but test scripts keep needing maintenance after launch. Bruno's CLI produces test reports that your pipeline must collect and publish. Recurring effort is the ongoing upkeep of scripts and of secrets injected at run time. Ask your team to confirm report formats and how credentials are supplied in each runner before you commit to a timeline.
Training and change management
Developers already used to Thunder Client's inside-editor workflow need time to learn Bruno's file-based collections and Git habits. This is a one-time cost in onboarding sessions and internal documentation, plus a smaller recurring cost for new joiners. Budget for reviewers who approve collection changes in Git, since that review step did not exist when collections lived inside the editor.
How a move from Thunder Client to Bruno proceeds
The sequence turns Thunder Client collections, environments and CI runs into Bruno folders that a team can version in Git, with a parallel period before the old workspace is retired. Effort depends on script complexity and the number of collections, so the inventory step sets the plan.
Inventory collections, environments and scripts
The team lead or a developer lists every Thunder Client collection, environment and variable set in use, and notes which requests carry pre- and post-request scripts, test assertions and embedded credentials. Each collection gets an owner and a flag for whether it is used in CI. The output is a written inventory that the rest of the sequence works from. You are done when every workspace in use appears on the list and no request is left unaccounted for.
Confirm available Thunder Client export formats
Before exporting anything, check with Thunder Client's documentation or your account settings which export formats your current plan allows, since import and export options differ by plan. Record whether collections can be exported in a Postman-compatible JSON format, and whether environments export separately. If the format you need is not available on your plan, raise it with the vendor before the migration is scheduled. You are done when the team has written confirmation of the export path it will use.
Export collections and environments in Postman format
A team member exports each inventoried collection and its environments in a Postman-compatible format and stores the files in a restricted folder, since they may contain credentials. The export is named by collection and date so it can be traced later. Bruno imports Postman collections exported in Collection v2 or v2.1 JSON format, so the export should match one of those versions. You are done when every collection on the inventory has a file and a checksum or record count is noted for comparison.
Import into Bruno and set up the Git repository
A developer imports each exported file into Bruno, then creates a Git repository for the collection folder so changes can be reviewed through pull requests. Bruno stores collections as files in a local folder, so the team decides whether to keep the repository in an internal Git server and whether to use the YAML format introduced in Bruno 3.0.0 or the default .bru files. Secrets should be moved to environment or local files kept out of version control. You are done when each imported collection opens in Bruno and its folder structure is committed to the repository.
Review translated scripts and variables
A developer compares each request against the original in Thunder Client and checks the scripts Bruno translated during import. Common Postman script APIs such as pm.test, pm.environment and pm.response are converted, but Postman-specific packages such as postman-collection and newman are flagged as unsupported and must be rewritten or removed. Variable scopes (collection, environment, global) are compared one by one. You are done when every flagged item is resolved and each request returns the same results as before on a test environment.
Move CI runs to bru run
The platform or DevOps engineer identifies each pipeline that calls the Thunder Client CLI and replaces the call with bru run, the Bruno CLI, pointing at the same collection folder and environment. Bruno's CLI provides test reports, so the team confirms the report format its pipeline expects and adjusts the parsing step. Secrets used by the pipeline are supplied from the CI system's secret store. You are done when each pipeline has run successfully against the Bruno collection and the team has seen the reports it expects.
Run both clients in parallel
For an agreed period, the team uses Bruno for new work while keeping Thunder Client workspaces available as a reference, and compares results for the same requests. Discrepancies are logged with the cause, such as a script difference or an unsupported package. Developers report any collection they still rely on in the old client. The period ends when the team lead confirms no open discrepancies remain. You are done when the discrepancy log is closed and every active user has moved their daily work to Bruno.
Retire the old workspace and record the decision
The team lead removes Thunder Client collections from shared workspaces, revokes seats that are no longer needed, and archives the final exports in the access-controlled location used during the migration. Plan changes are checked with the vendor so that no recurring charge continues after the move. The migration record lists the inventory, the export files, the open items and the owner of each Bruno collection. You are done when the record is filed and the old workspace no longer receives new requests.
Questions buyers ask before switching from Thunder Client
What does a move from Thunder Client to Bruno cost in effort, and who pays for it?
Bruno's desktop client is free under the MIT License, so the software itself carries no license fee on the Open Source edition. The cost is effort: someone exports collections and environments, imports them, reviews scripts and variables, and updates CI jobs. Internal engineers pay that cost in time, while an outside partner bills for the same work under a written scope. Paid Bruno editions are priced per user per month, with Pro at $6 and Ultimate at $11, both billed annually, according to Bruno's pricing page. Ask for a per-seat breakdown and whether your team needs any paid feature at all before you budget.
How long does a migration take, and what drives the duration?
The duration depends mostly on the size and condition of your collections, not the tool. A small set of requests with simple auth can move in a short session, while large workspaces with chained requests, custom scripts and many environments take longer to verify. The main drivers are the number of collections, how much logic lives in pre-request and test scripts, how many people must sign off, and how many CI pipelines call the Thunder Client CLI. Confirm the count of collections and scripts in your workspace first, since that inventory sets the realistic schedule.
Can our team switch to Bruno without outside help?
Yes, a team can usually switch on its own if it has a clear owner, time to test, and at least one engineer comfortable with scripting. Bruno imports Postman collections in Collection v2 or v2.1 JSON format, which covers many common cases. Bulk import of a full Postman data dump is limited to the Ultimate edition, so a team switching from many collections may need to import them one by one. Plan for manual review of scripts, because Bruno flags Postman-specific packages such as postman-collection and newman as unsupported.
What do we need to provide during the switch?
You need four things: access to the Thunder Client workspaces and export rights for every collection and environment, a person who reviews translated scripts and variables against expected behavior, a Git repository or shared folder where the new Bruno collections will live, and a named owner for each CI job that runs collections today. Thunder Client's CLI runs must be replaced with Bruno's bru run command, so the CI owner should confirm the pipeline steps, report format and secret handling before cutover.
Does Bruno's free edition cover our needs given the workspace limit?
Bruno's Open Source edition is free, but it limits you to 2 workspaces and 5 OpenAPI syncs per month, according to Bruno's pricing page. Count how many separate workspaces your teams need today, not how many collections. Git push, branch operations, remote connections and merge conflict resolution inside the app are paid features, though Git itself still works from the command line on any edition. If your teams rely on those Git UI actions or need SAML single sign-on and SCIM provisioning, check the paid editions before you commit.
Where are collections stored after the move, and does that affect security?
In Bruno, collections are stored as files in a folder on each user's filesystem, and the README states the app is offline-only with no plans for cloud sync. That keeps collections, including any credentials embedded in them, on machines you control, subject to your own access controls and backups. Teams that share through Git should confirm that secrets are kept out of committed files and that the repository's access rules match your policy. Ask your security team to review this before rollout.
When is it worth engaging an outside implementation partner?
Engage a partner when the migration touches many collections, regulated data, CI pipelines that must keep passing, or staff who lack time to test. DeployOpen implements self-hosted open-source platforms in your own infrastructure and works under a fixed scope with agreed deliverables and timelines set in writing before work starts. A partner can also prepare evidence for compliance assessments, though independent auditors issue any attestations. Ask for a written scope that lists the collections, scripts, CI jobs and acceptance tests covered, then compare quotes against that same list.
How DeployOpen helps teams evaluate and move API clients
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure, so an API client decision is handled as a written scope rather than a tool trial. We can help you test Bruno against your current Thunder Client collections, then support the move to a repository-based workflow your team controls.
How we scope
- Inventory which Thunder Client collections, environments and CI runs your teams depend on before choosing a target
- Agree in writing which request types, scripts and variables are in the migration and which are retired
- Define who keeps collections in Git, who reviews changes and where the repository is hosted
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Import sample collections into Bruno and check how Postman-format scripts and environment variables translate
- Set up the bru CLI in your pipeline so collections run with test reports in your own build environment
- Review credential handling so secrets stay out of committed collection files and sit in controlled environments
- Document the folder layout, naming conventions and Git branching rules your teams will follow
How we hand over
- Deliver a runbook covering installation, collection structure, environment setup and the CI run steps
- Walk through migrated requests with each team so the test coverage matches what they had before
- List the features that differ from Thunder Client, including any paid Bruno editions you choose to buy
- Record the decisions made during scoping so future changes have a written reference
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover tracking Bruno releases and testing collections after each upgrade
- Ask for a quote that separates one-time migration work from any recurring support you need
- Confirm with your own security and procurement teams which support terms fit your environment
