Migrate from Thunder Client to Bruno

Migrate from Thunder Client to Bruno without losing requests or test logic

Teams that run Thunder Client inside VS Code and now need their collections kept as files on their own devices or in Git usually face one of two triggers: plan limits or a pricing change. The move itself is a data export and import, followed by rework of scripts, variables and CI runs. Engineers on the team typically do the work, and outside help is most useful for agreeing the scope of what moves, setting the cutover date and checking that test results match before the old setup is switched off. The storage model changes: Thunder Client lives inside the editor, while Bruno is offline-only and stores each collection as files in a folder on the filesystem, so teams can collaborate through Git or another version control system.

Before exporting anything, inventory what each collection depends on. Confirm which requests, environments and collection-level variables are in active use, and list any credentials or tokens embedded in them, since those now sit in files that will be committed or shared. Decide early where the Bruno folder lives, who can push to its repository and how secrets are kept out of committed files. Confirm with Bruno's documentation which export format your Thunder Client version produces and whether the Postman import path covers your exported files, because the import route determines how much manual cleanup follows. Plan a short pilot on one collection before moving the rest.

What maps from Thunder Client to Bruno and what needs rework

This table compares the main parts of a Thunder Client workspace with their Bruno equivalents and marks each as clean, needs rework or gap. Read the status column first, then check the row for your own collections, since most teams will find a mix of all three.

Element	Bruno equivalent and status	What to check before migrating
Requests and folders	Clean: requests and folders map to Bruno requests and folders, stored as files in a local directory	Confirm the folder hierarchy survives your export, then review request names for characters your file system or Git setup handles poorly
Environments	Needs rework: environments are imported from Postman environment files and become Bruno environments	Check that secret values are not carried into shared files, since Bruno keeps collections in a folder you control
Variables	Needs rework: Postman-style variable syntax is converted, but scope rules may differ	Test each collection and global variable after import, and confirm which scope each one resolves to
Auth	Needs rework: common auth types usually import, but token handling and OAuth flows need a manual test	Send one authenticated request per auth type and compare the response with Thunder Client
Pre-request and test scripts	Needs rework: pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response are translated on import	Flag any script using postman-collection or newman, since Bruno marks these as unsupported and they need rewriting
Collection runs	Needs rework: Bruno's runner covers the same job, but run order, data files and reports should be checked	Compare run results on a staging endpoint before retiring the Thunder Client run
CI usage	Gap to confirm: Thunder Client's CLI behavior is not covered by the sources here, so map its CI steps to bru run	Ask your team to list every CI job that calls the Thunder Client CLI, then rebuild each with bru run and its test reports
OpenAPI specs	Secondary path: Bruno's bru import command can create collections from OpenAPI	Use this path for generated collections only after confirming which operations and examples are included

Which data moves, which integrations must be rebuilt

Collections, environments, scripts and CI invocations do not all move the same way. Bruno documents an import path for Postman-format collections and an OpenAPI path, but the rest is a manual rebuild that the team should plan before the Thunder Client license ends.

Collections and request structure

Export collections from the Thunder Client workspace and import them into Bruno as Postman Collection v2 or v2.1 JSON. Bruno writes each collection as a folder of files on disk, so the import creates a structure that can be committed to Git and reviewed in pull requests. Check folder nesting, request names, auth settings and body types after import, because these are the fields most often lost in translation. If the team keeps an OpenAPI specification, the bru import command can build a collection from it as a second starting point.

Environments and their secrets

Environment variables are not carried over as a single step that the team can assume is complete, so compare each environment against the Thunder Client source. Credentials embedded in requests, headers or environments move with the collection files, which means they stay on machines and repositories the team controls. Decide which values belong in committed environment files and which should be supplied locally at run time, and keep production tokens out of Git history.

Scripts and variable references

Bruno translates common Postman script APIs such as pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response during import. Scripts that depend on Postman-specific packages such as postman-collection or newman are flagged as unsupported and must be rewritten by hand. Review every pre-request and test script, and run each request once against a non-production server to confirm that assertions still fail when they should.

CI invocations and test reports

Thunder Client's command-line runner does not transfer to Bruno, so pipeline steps must be rewritten to call bru run from the Bruno CLI. Confirm which environment file, data file and report format each pipeline needs, and check that exit codes still fail the build when a test fails. Bruno's CLI documentation covers how runs and test reports are produced, so the team should test a pipeline on a branch before switching over.

Licensing and access for the team

Open-source Bruno users need no license management, so there is no key to issue or renew for each developer. Paid Bruno editions add license keys, SAML single sign-on and SCIM provisioning, which matter only if the organization needs centrally managed identity. Confirm with the vendor which features your team requires before choosing an edition, because Git push, branch operations and merge conflict resolution in the app's Git UI are paid features, while Git itself works outside the app on any edition.

Migration sequence from inventory to decommission

This sequence moves Thunder Client collections, environments, scripts and CI jobs into Bruno in controlled stages, so each team proves its requests work before Thunder Client is removed. Each step ends with a concrete artifact you can check.

Inventory collections, environments, scripts and CI jobs
Make a written list of every Thunder Client collection, environment, variable set, pre-request and test script, and every pipeline or script that calls the Thunder Client CLI. Note the owner of each item, which requests use credentials, and which requests depend on other requests through chained variables. Ask the team leads to confirm the list, since personal collections on individual laptops are the most often missed. The output is a signed-off inventory that shows what must move, what can be retired, and what needs a decision.
Pilot one collection end to end
Choose one representative collection that uses environments, auth and at least one test script. Export it from Thunder Client, check that the export format is one Bruno can import, and bring it into Bruno by importing a Postman Collection v2 or v2.1 JSON file. Run every request against a non-production environment and compare responses and test results with the Thunder Client run. The pilot is done when the collection passes with the same results as before, and the team has written down each change they made to scripts or variables.
Store the pilot collection in Git
Create a repository for the collection and keep the Bruno collection folder in it, since Bruno stores collections as files in a local folder for Git collaboration. Decide how secrets are handled before the first commit: keep credentials in environment files or a secrets store that is not committed, and confirm that no token ends up in the repository history. Share the repository with the pilot team and have one reviewer open a pull request for a small request change. The output is a Git-backed collection with a documented branch and review workflow.
Import remaining collections and fix variables and scripts
Import the rest of the inventory in batches, grouped by owner or service. Expect that Bruno translates common Postman script APIs such as pm.test, pm.environment and pm.response, but flags Postman-specific packages such as postman-collection and newman as unsupported, so review every flagged script by hand. Rewrite variable references where environment names differ, and re-test each batch against the same backend. Bulk import of a full Postman data dump is a paid Bruno Ultimate feature, so plan for per-collection imports under the open-source edition. The output is a set of collections that each pass their own test run, with a list of any script that needed a rewrite.
Run both clients in parallel while teams switch
Let each team use Bruno for daily work while Thunder Client stays installed for a short overlap, so anyone who finds a gap can fall back without losing work. Track open issues in one shared list with the owner, the request affected and the fix. Confirm with each team that its daily requests, including authenticated calls, return the same results in both clients. The overlap ends when the open list is empty and every team lead has confirmed in writing that their collections are complete in Bruno.
Cut over CI to bru run with test reports
Replace each Thunder Client CLI job in the pipeline with a Bruno CLI job that runs the collection with bru run, and configure it to write test reports so pipeline results stay visible in the same way. Run the new job alongside the old one on the same commits until both produce matching pass and fail results. Store any CI credentials in the pipeline's secret store, not in the collection. The output is a CI pipeline that runs bru run on every relevant commit and reports results to the same place the team already looks.
Decommission Thunder Client and retire its data
Once daily use and CI have both run on Bruno for an agreed period, remove the Thunder Client extension from every workstation and disable the CLI jobs that still call it. Archive the exported Thunder Client collections in a restricted location, then delete any copies that contain credentials once the archive is confirmed. Check that the Thunder Client account and any paid seats are closed according to the vendor's current terms, and confirm the closure with your procurement team. The output is a documented decommission record listing removed extensions, retired jobs, archived exports and the approver for each step.

What drives migration effort and how to keep it down

This table lists the factors that change how much work a Thunder Client to Bruno move takes and the cost components behind each one. Read each row as a lever: the driver, why it matters, and what you can do to reduce it before cutover. The main takeaway is that script complexity, secret handling and CI job count usually matter more than the raw number of collections.

Driver	Why it changes effort or cost	How to keep it down
Number of collections and requests	Each collection needs an export, an import, a review and a test send. Effort grows with request count and with duplicated requests across folders.	Inventory collections first, delete unused ones, and merge duplicates before export. Migrate in batches by project.
Pre-request and test scripts	Thunder Client scripts must be checked against Bruno's script API. Scripts that depend on custom logic need manual rewriting and retesting.	List every script, flag the ones that use pm.* calls, and convert the simplest ones first. Keep a short test case per script.
Postman-specific packages	Bruno flags packages such as postman-collection and newman as unsupported, so any code that requires them must be replaced.	Search exported collections for require calls to Postman packages before import. Replace them with plain JavaScript or Bruno built-ins.
Environment secrets	Secrets stored in Thunder Client environments must be moved to Bruno environments without leaking into Git. Handling these values takes a careful review.	Keep secret values out of committed files. Use local environment files or your secret store, and check the export for embedded credentials before sharing it.
CI job count and CLI usage	Each Thunder Client CLI job must be rewritten to run bru run and its reports checked. More jobs mean more pipeline edits and test runs.	Map each CI job to a bru run command, start with one pipeline, and confirm report output matches what your team reads today.
Team size and Git workflow needs	Git collaboration on .bru or YAML files needs a shared branching habit. Git push, branch operations and merge conflict resolution in the app are paid features in Bruno's Pro and Ultimate editions. Pro is listed at $6 per user per month and Ultimate at $11 per user per month, both billed annually, according to Bruno's pricing page.	Decide early whether engineers use Git outside the app, which the Open Source edition allows. Buy paid seats only for people who need the in-app Git operations or bulk Postman import.
Outside scoping and cutover support	Fixed-scope help from DeployOpen covers scope, deliverables and timelines agreed in writing before work starts. The cost depends on the inventory and CI work in that scope.	Ask for a written scope that lists collections, scripts, CI jobs and the acceptance checks. Ask what is excluded, such as script rewrites or retraining.

What usually goes wrong and how to prevent it

Most failed moves from Thunder Client to Bruno come from a few predictable places: scripts, secrets, variables, CI and ownership. Each card below names one risk and a check to run before the old client is retired.

Unsupported Postman packages break scripts

Thunder Client scripts that import helper packages can stop working once they reach Bruno. Bruno translates common Postman script APIs such as pm.test, pm.environment and pm.response during import, but it flags Postman-specific packages such as postman-collection and newman as unsupported. Before cutover, search every imported script for require or import statements, rewrite each flagged call in plain JavaScript, and run each request once against a non-production environment to confirm the test results match the old client.

Secrets exported in plain files

Exported collections and environments can carry tokens, API keys and passwords in clear text. A Postman-format export is a plain JSON file, and anyone who receives it or finds it in a repository can use those credentials. Strip secret values from exports, move them into Bruno environment variables or your existing secrets store, and confirm the exported files are not written into any shared folder before they reach version control.

Secrets committed to Git

Bruno stores collections as files in a local folder so teams can use Git, which also means a commit can publish credentials to everyone with repository access. Keep environment files that hold secrets out of the repository, add their names to .gitignore, and review the first commit of each migrated collection before pushing. Treat any secret that reached a shared remote as compromised and rotate it.

Variables resolved differently after import

Variable scope and precedence can differ between clients, so a request that used a value from one environment in Thunder Client may read another value, or none, in Bruno. Compare each imported environment with its source, check collection-level and folder-level variables separately, and run a sample request from each environment to confirm the resolved URL, headers and body match the original.

CI jobs left on the old CLI

Pipelines that still call the Thunder Client CLI will keep running against collections that no longer change, which gives false confidence. Move each job to bru run, the Bruno CLI, and compare its test report with the previous results on the same collection. Remove the old CLI step only after both pass for a full release cycle, and ask your CI owner to confirm the report format your build tooling expects.

Two clients with no owner

Teams that move gradually often keep Thunder Client and Bruno side by side, and then the two copies of each collection drift apart. Assign one owner for each collection, name the single source of truth, and set a date for disabling edits in the old client. Without that decision, the team will not know which requests are current when a bug report arrives.

Expecting Git push or bulk import on the free edition

The Open Source edition of Bruno covers clone, initialize, diffs, pull and commit in its Git UI, while Git push, branch operations, remote connections and merge conflict resolution in the app are paid features. Bulk import of a full Postman data dump is included only in the Ultimate edition, and Open Source is limited to 2 workspaces. Confirm which features your team needs before the migration plan assumes them, and use Git from the command line where the free edition does not cover a step.

How the move differs by team size and starting point

A single developer moving personal collections usually has the simplest path. The main task is exporting Thunder Client collections and environments, importing them into Bruno, and checking that requests and scripts still behave as expected. Bruno's open-source edition handles this import from Postman-format JSON, so a solo user normally does not need a paid edition for the migration itself. Bruno stores each collection as files in a local folder, so the result sits on your own device.

Export first: Export each Thunder Client collection and environment in Postman format before uninstalling anything, and keep the files in a safe location.
Import one collection at a time: Start with a small collection to see how variables, auth and scripts come across.
Review scripts: Thunder Client scripts may use APIs that need manual rewriting after import.
Keep the folder: The Bruno collection folder is the source of truth, so back it up like any other project files.
Plan for a second device: Without a sync service, copying the folder or committing it to Git is your responsibility.

Confirm which Thunder Client features your collections depend on, such as environment secrets, before you rely on the import.

A team that runs collections in continuous integration must move the test runs, not only the requests. Thunder Client's command-line runner is part of its paid model, so the team has to rebuild pipeline steps around Bruno's command-line tool. Bruno provides bru run with test reports, and the pipeline needs the collection files, environment selection and secrets available at run time. Migrating CI is usually a separate project from migrating the desktop client.

Rebuild the run command: Replace the Thunder Client CLI step with bru run and check how environments are selected.
Reports for the pipeline: Confirm the report format your pipeline or dashboard reads, since Bruno's reports may differ from the previous output.
Secrets at run time: Inject credentials from the CI secret store rather than committing them to collection files.
Run in parallel with the old setup: Compare results from both runners on the same endpoints before switching the gate.
Versions: Pin the Bruno CLI version in the pipeline so test behavior does not change unexpectedly.

Confirm the CLI options, report formats and secret handling in the Bruno CLI documentation and in your own pipeline before you retire the Thunder Client step.

Questions buyers ask before moving from Thunder Client to Bruno

How long does a migration from Thunder Client to Bruno take?

No supplied figure gives a duration, so the honest answer depends on your collection count, environment count and script complexity. Bruno's Postman import handles collections exported as Collection v2 or v2.1 JSON, so the first pass is mostly export and import. The time goes into reviewing imported requests, rewriting scripts and checking variables. Ask DeployOpen for a written scope that lists the collections, environments and scripts in your inventory, then compare that scope against your own sample of requests before agreeing on a timeline.

Can our team migrate from Thunder Client to Bruno without outside help?

Yes, a small team can do the basic move alone, because Bruno is a desktop client and its import path needs no server. Thunder Client's export and Bruno's import both work from files, so an engineer can run a trial with one collection first. Help is most useful when you have many collections, scripts that depend on Thunder Client behavior, or CI jobs that must keep passing during cutover. Confirm with your engineers how much of the work they can absorb alongside current delivery.

What does the migration require from our engineers and the business?

The work needs three things from your side:

Someone who can export collections and environments from Thunder Client and check what was exported.
Engineers who understand the test scripts and variables, since these need manual review after import.
A decision on where collections will live, such as a Git repository, because Bruno stores collections as files in a local folder.

Business owners should also confirm which teams depend on the shared collections so cutover happens with notice.

Does Bruno cost money for our team size?

The Open Source edition of Bruno is free, and its desktop app and bru CLI are licensed under the MIT License. The pricing page lists Pro at $6 per user per month and Ultimate at $11 per user per month, both billed annually. The Open Source edition is limited to 2 workspaces and 5 OpenAPI syncs per month, and Git push, branch operations, remote connections and merge conflict resolution in the Git UI are paid features. Bulk import of a full Postman data dump is included only in Ultimate. Check the current terms on the pricing page and confirm which features your workflow needs before budgeting.

What happens to Thunder Client scripts that use Postman packages?

Bruno translates common Postman script APIs during import, including pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response. It flags Postman-specific packages such as postman-collection and newman as unsupported, so those scripts need manual rewriting. Scripts written for Thunder Client may use its own API, which is not covered by the Postman translation, so review every script after import. Run each collection against a staging environment and compare results before retiring the old collection.

How do CI runs change when we move to Bruno?

CI moves from the Thunder Client CLI to the Bruno CLI, which runs collections with bru run and can produce test reports. Your pipeline definition, secrets handling and report format will change, so update the job and confirm the output your CI system expects. Pipelines that depend on Thunder Client-specific features need rework. Run the old and new jobs side by side for a period you choose, and document the command, environment file and report location for your engineers.

Where do collections and credentials live after the move?

Bruno keeps collections as plain files in a folder on the user's own filesystem, and its README states it is offline-only with no plans for cloud sync. This means credentials stored in environments stay on devices and repositories you control, though you must set rules for how secrets are kept out of Git. Confirm with your security team how environment files with credentials will be handled, and whether any file-based secret storage policy applies.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside your own infrastructure. For a Thunder Client to Bruno migration, we start from a written scope that names the collections, environments and CI jobs to move, then carry out the work and hand over a documented result your team can run.

How we scope

Inventory every Thunder Client collection, environment and CI job that needs to move to Bruno
Agree in writing which requests, scripts and variables are in scope and which are retired
Engagements are fixed-scope, with deliverables and timelines agreed before work starts

How we build

Export collections and environments, import them into Bruno and check each request against its original
Review imported scripts and variables, rewriting any logic that does not carry over cleanly
Convert CI runs from the Thunder Client CLI to bru run and confirm test reports are produced

How we hand over

Deliver a Git-ready Bruno collection folder with a short guide on structure and naming
Document the CI pipeline changes, required secrets and how credentials are kept out of files
Walk your engineers through daily use and record the checks that confirmed parity

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Scope any later Bruno version upgrade or new CI pipeline as a separate written change
Ask us to confirm current Bruno edition features and licensing before you commit to a plan

Migrate from Thunder Client to Bruno