Insomnia vs Bruno: which API client fits your team
Insomnia fits teams already working inside Kong's account model that want hosted sync and are comfortable with collections living in Kong's cloud. Bruno fits teams that want offline-only collections stored as files and reviewed in Git, with no vendor account required to open or run them. Bruno's README states that it is offline-only and that there are no plans to add cloud sync, so the choice often comes down to whether a vendor-hosted copy of your requests and credentials is acceptable at all.
Start with where collections must live. If API requests, environment values or embedded tokens cannot leave your devices or network, check which Insomnia features your team depends on, such as Cloud Sync or Git Sync projects, and confirm with Kong how each is stored and what the account requires. Then list the paid features you actually use. Bruno's pricing page marks Git push, branch operations, remote connections and merge conflict resolution in its Git UI as paid, while clone, pull, commit and diffs are in the Open Source edition. Git itself works outside the app on any edition, so ask whether your team can run its review flow from the command line.
Next, decide whether collections must run in CI, since Bruno provides bru run with test reports. Count the seats in scope and price them from current vendor pricing pages, not from memory: Bruno lists Pro and Ultimate per user per month, billed annually, and limits the Open Source edition to 2 workspaces and 5 OpenAPI syncs per month. Confirm those limits and any Insomnia seat terms with each vendor in writing before you compare totals.
Which client fits which team situation
This table matches common team situations to the client that fits best and notes when Insomnia's account-based features would still matter. Read each row against your own constraints, since the right choice usually depends on where collections may live and who signs in.
| Situation | Better fit | Reason and when Insomnia would matter |
|---|---|---|
| Collections must stay off any vendor cloud | Bruno (offline-only) | Bruno stores collections as files in a local folder and has no cloud sync, so nothing leaves the device by default. Insomnia would matter only if the team accepts a Kong account for its cloud features. |
| Team already keeps API specs in Git | Bruno with Git | Collections sit beside code and go through the same review and branching. Git push and merge conflict handling in Bruno's app are paid features, though Git itself works outside the app on any edition. |
| Distributed team needs shared cloud workspaces | Self-hosted Hoppscotch | A Hoppscotch instance on your own server gives shared workspaces without a vendor cloud. Insomnia fits better if the team already runs its work inside Kong's hosted platform and accepts that dependency. |
| Collections run in CI pipelines | Bruno CLI or Hoppscotch CLI | Bruno's bru run produces test reports and Hoppscotch's hopp test writes JUnit XML, both suited to pipelines. Confirm the report format and runner setup against each tool's CLI documentation for your pipeline. |
| SSO and SCIM required for every user | Confirm before choosing | Bruno's paid editions cover SAML single sign-on and SCIM through a license portal, and Hoppscotch Enterprise lists SAML SSO and SCIM. Ask each vendor which edition and which identity provider they support. |
| Team relies on Postman collections today | Bruno or Hoppscotch import | Both tools import Postman Collection v2 and v2.1 JSON. Bruno's bulk import of a full Postman data dump is an Ultimate edition feature, so check which migration path your volume needs. |
| Team depends on Insomnia cloud sync across many devices | Insomnia until migration is planned | Cloud Sync and Git Sync projects are the main reason to stay on Insomnia. Plan the export of those projects before switching so no collection is lost. |
Where collections live and how teams share them in Git
Bruno is offline-only, and its README states there are no plans to add cloud sync. Collections are stored directly in a folder on the user's filesystem, so a team shares them through Git or any other version control system. That is the core storage decision in this comparison: with Bruno, the collection is a set of files your team owns, reviews and branches like source code. Insomnia takes the opposite approach. Its Local Vault, Git Sync and Cloud Sync options all sit behind a Kong account for most features, so where a collection lives and who can read it depends on how your organization configures Kong's services, not only on your repository.
File-based Git review fits better when your API changes already go through code review. A request change, a new header, an updated assertion or a modified environment variable appears as a plain-text diff that an engineer can comment on in the same pull request as the service change. Before you commit to this model, confirm two things: that your Git host and review workflow suit committed API collections, and that your team agrees which environment files, if any, may contain secrets. Bruno's Git UI features beyond clone, pull, diff and commit are listed as paid on its pricing page, so check which operations your team will perform inside the app and which will run in the command line.
Hosted sync is the simpler choice when the team is mostly non-engineers, when collaborators need to see and edit requests without touching Git, or when you want the vendor to handle sharing and access. The trade-off is that the collection's location and access rules move into the vendor's account model, which is exactly what a data residency or lock-in review needs to examine. Ask Kong which Insomnia features require an account in your plan, and document where any Cloud Sync or Git Sync project data is stored before you migrate collections.
What data control means for credentials and collections
Moving an API client is partly a question of where collections, environments and secrets sit once the team relies on them. The cards below cover storage, credentials, account dependencies, license administration, identity options and compliance evidence, so the comparison with Insomnia rests on checks you can run rather than assumptions.
Where collections and environments live
Bruno stores collections as plain files in a folder on the user's filesystem, so the team decides where that folder sits and how it is shared, typically through Git. Insomnia's Local Vault and Git Sync options sit alongside Cloud Sync, which is tied to a Kong account for most features. Ask which Insomnia features your team uses today and confirm where each of them keeps data before you map the move.
How embedded credentials are handled
API collections often hold bearer tokens, API keys, basic auth passwords and client secrets inside requests, headers or environment variables. In Bruno, these values sit in files you control, so you decide whether they are committed, kept in environment files that are excluded from Git or resolved from a secrets store. Review every exported file for live credentials before it leaves the original app.
What a Kong account changes for data flow
When most Insomnia features require a Kong account, collection data and the account metadata around it pass through a vendor service that your security team must assess. Bruno's offline-only model removes that cloud path for collections, although the Git remote you pick and any OpenAPI sync you enable still create their own data flows. Document each path your team uses and confirm it with the vendor's current terms.
Who holds Bruno's paid license keys
Open-source Bruno users need no license management. Pro and Ultimate editions use license keys issued through a license portal, so the account holder who buys seats controls key assignment and renewals. Name a licensed administrator, record which seats are active and plan for key rotation when people leave the team.
Identity and SSO by tier
Bruno's paid editions cover SAML single sign-on and SCIM provisioning through the license portal, while the open-source edition relies on local use with no central sign-in. Insomnia's SSO and provisioning depend on its own plan structure. Compare the exact sign-in and deprovisioning features each tier offers against your identity provider policy, and confirm them in writing before you buy.
Compliance evidence stays with your auditor
A tool's data model helps you build controls, but it does not prove compliance on its own. Ask your independent auditor which evidence they need for access control, change history in Git, credential handling and retention, then confirm each item against the vendor documentation and your own configuration. Treat the vendor's statements as inputs to that review, not as a substitute for it.
How the Bruno and Insomnia editions differ
The Bruno Open Source edition is the zero-cost option. It is released under the MIT License, and it stores each collection as files in a folder on the user's device, so no account or vendor cloud sits between the team and its requests. Teams that want shared history use Git outside the app, and the edition covers the core Git actions inside the app.
- License: MIT, which permits free use and modification of the open-source code.
- Price: $0 per user on the pricing page.
- Workspace limit: 2 workspaces on this edition.
- OpenAPI sync limit: 5 OpenAPI syncs per month.
- Git in the app: clone, initialize, diffs, pull and commit are included, while push and branch operations require a paid edition.
Before you standardize on this edition, count the workspaces each team needs and estimate how often engineers will sync OpenAPI definitions, because both limits are fixed on the pricing page.
Bruno's paid editions add per-user pricing, billed annually, for features that matter once several people push to the same Git repository or onboard from Postman at scale. The Pro edition is listed at $6 per user per month and the highest-priced paid edition at $11 per user per month. Paid editions run on license keys that are managed in a license portal, and that portal is also where SAML single sign-on and SCIM provisioning are handled.
- Pro seats: $6 per user per month, billed annually, according to the pricing page.
- Top paid seats: $11 per user per month, billed annually, with bulk import of a Postman data dump of all collections and environments.
- Git UI features: push, branch operations, remote connections and merge conflict resolution are paid, while Git itself still works outside the app on any edition.
- Identity features: SAML SSO and SCIM run through the license portal, so check that your identity provider works with that setup.
- Seat model: cost recurs per user, so headcount changes move the annual total.
Confirm with Bruno which edition includes each feature your team needs, how seats are counted for contractors and service accounts, and whether the license portal meets your identity requirements.
Kong Insomnia publishes its core under the Apache-2.0 license, but its paid Pro and Enterprise plans are built around a Kong account. For most of the features that matter to teams, including Cloud Sync and Git Sync, the workflow depends on that account and Kong's services. Local Vault is the storage option that keeps data on the device, so the exact boundary between offline and account-linked features is the first thing to map for your team.
- License model: Apache-2.0 for the core application, with paid plans layered on top.
- Account dependency: most Pro and Enterprise features require signing in to a Kong account.
- Sync options: Cloud Sync and Git Sync are tied to Kong's service and plan structure.
- Seat cost: Kong sets per-seat pricing for each plan, and no figures are given here.
- Admin controls: the identity and governance features in each plan vary, so confirm them against the plan you would buy.
Before comparing totals, list which of your current Insomnia workflows depend on an account, because that list determines whether the paid plan is required at all.
Several points in this comparison depend on Kong's current product terms, which can change between releases. Treat the Insomnia side as a list of questions to verify in writing, rather than as settled facts. Ask for the answers before a renewal or migration decision, and record the version you tested.
- Seat pricing: current per-seat prices, billing period and minimum seat counts for each plan.
- Offline behavior: which features work fully without a Kong account in the version you run, including Local Vault and any scratch-style workspace.
- Git Sync limits: the number of users included in each plan and what happens when that number is exceeded.
- Identity features: which plans include single sign-on and provisioning, and how they are configured.
- Data handling: where account-linked data is stored and processed, and how it can be deleted.
Ask Kong for these answers in writing and compare them with the Bruno pricing page before you finalize any seat count.
Scripting, Postman compatibility and CLI runs in CI
Before you commit a team to Bruno, check how your existing scripts behave after import, because that is where most migration effort lands. Bruno translates common Postman script APIs during import, including pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response. Packages such as postman-collection and newman are flagged as unsupported, so any script that calls them will not run as written. Export a representative set of collections from Postman in Collection v2 or v2.1 JSON, import them into Bruno, and read the flagged items in the import output. Treat each flag as a rewrite task with an owner, not as a warning to ignore. The Bruno migration guide lists the translated APIs, and the scripts in your own collections will show whether those are enough for your tests.
For pipelines, Bruno's command line tool runs collections outside the desktop app. The bru run command executes a collection and can produce test reports that a CI job can store as build artifacts, so failing assertions show up in the same place as failing unit tests. Run the same collection with the same environment file in a CI job and in the app, and compare the results. Pay attention to secrets: environment values that the app reads from a local vault or an operating system keychain must be supplied to the pipeline through the CI system's own secret store, not committed to Git. Confirm the exact flags and report formats in the Bruno CLI documentation against the version your team pins.
Insomnia's command line capabilities are a separate question, and you should confirm them directly before deciding. Check which Insomnia CLI tool covers test execution, whether it can run requests from a collection file in a headless job, how it reads environment secrets, and which report formats it writes. Compare that list with the Bruno steps above, using the same collection and the same failing and passing assertions in both. Also record which of your scripts depend on features that differ between the two tools, such as request chaining or custom libraries, so the decision rests on your collections rather than on a feature list.
What each option costs per seat and what drives the total
What does Bruno cost per seat?
Bruno's Open Source edition is $0, and its paid editions are priced per user: Pro at $6 per user per month and Ultimate at $11 per user per month, both billed annually, according to Bruno's pricing page. The Open Source edition is limited to 2 workspaces and 5 OpenAPI syncs per month, so a team that needs more workspaces or syncs has to move to a paid edition or split its work. Confirm the current figures on the Bruno pricing page before you build a budget, because pricing can change between editions and billing periods.
How many seats do we need and why does it matter?
Seat count is the multiplier for every per-user price, so it is the first number to settle. Count the people who will edit collections, not everyone who only runs them, and separate them from CI runners, which use the command-line runner rather than a desktop seat. Keep the count current, because adding contractors or engineers changes the total every month. Ask Kong and Bruno how each one counts seats, including whether guests, viewers or service accounts are billed.
Which paid features do we actually need in Bruno?
Paid Bruno editions add features that the Open Source edition does not include. According to Bruno's pricing page, these are:
- Git push, branch operations, remote connections and merge conflict resolution in the app's Git UI
- Bulk import of a Postman data dump, which Bruno Ultimate Edition includes
- SAML single sign-on and SCIM provisioning on the paid editions
Clone, initialize, diffs, pull and commit stay in the free edition, and Git works outside the app on any edition. Teams that already run Git from the terminal may need no paid seat at all. Check each feature against your real workflow before you assume you need a paid seat.
What should we ask Kong for when requesting an Insomnia quote?
DeployOpen does not hold Insomnia prices, so request the current seat price directly from Kong. Ask for the per-seat price for each Insomnia tier you would use, the minimum seat count, and whether billing is annual or monthly. Also ask which features sit behind each tier, including Git Sync, Cloud Sync and SSO, and whether the Git Sync limit on the Essentials tier applies to your team size. Then compare the quote with the features your team uses today, not with the full feature list on the sales page.
What costs are one-time and what costs recur?
One-time costs cover moving collections, converting scripts, checking authentication and environments, and training the team on the new client. Recurring costs cover seats or licence renewals, the time spent on upgrades, and support for whatever runs the tool. For Bruno, the licence cost recurs only on paid editions. For a self-hosted Hoppscotch instance, hosting, backups, patching and upgrades recur on your own staff's time. Ask every vendor and partner to split their quote into these two groups so you can compare the first year with later years.
How much migration labor should we plan for Bruno?
The main effort is in the collections, not the import button. Bruno imports Postman collections in Collection v2 or v2.1 JSON, and it translates common Postman script APIs such as pm.test and pm.environment during import. It flags Postman-specific packages such as postman-collection and newman as unsupported, so those scripts need hand rewriting. Count the collections, environments and scripts that use those packages, then review authentication and environment variables. The effort grows with the number of custom scripts and shared environments, so ask any partner to estimate by collection and script count in the written scope.
What admin and rollout effort does each option add?
Bruno's desktop client needs little administration, since users install it on their own devices and the collections live in a Git repository your team already manages. Admin effort then moves to Git access, branch rules and, on paid editions, license keys and the license portal. A self-hosted Hoppscotch instance adds more work: someone must install, configure the database, apply upgrades and back up the data. Ask who owns each of these tasks, and write that owner into the rollout plan before you buy seats.
Can our own staff run the rollout, or do we need outside help?
Many teams can run a Bruno rollout themselves, provided they have someone comfortable with Git and the scripting migration. Outside help makes sense when collections are large, when scripts depend on Postman-specific packages, or when the team needs a self-hosted Hoppscotch instance with sign-in and backups in place. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope.
How a move from Insomnia to Bruno usually runs
The sequence turns Insomnia collections that sit in Kong's cloud or in Git Sync projects into a Git-tracked Bruno collection that the team has checked for parity before the old projects are retired. The detailed steps live on the migration page.
Inventory projects and sync usage
Start by listing every Insomnia workspace, project and collection, and note whether each one uses Local Vault, Cloud Sync or Git Sync. Assign an owner to each project and record who relies on it day to day. This inventory is the baseline for the rest of the move. It is done when every project has an owner and a sync status, and the team agrees which projects are in scope for Bruno.
Export Insomnia data as v5 YAML
Export each in-scope collection and its environments from Insomnia in the v5 YAML format. Before any file leaves the app, review environments and authentication settings for stored secrets and remove or move them into a controlled store. The check is complete when each collection has a matching export file that the owner has opened and confirmed contains the expected requests and folders.
Import the collections into Bruno
Import the exported files into Bruno. Bruno also reads older Insomnia v4 JSON, so teams that still hold v4 exports can use those without re-exporting. Confirm that folder structure, request bodies, headers and variables arrived intact. The step is done when the imported collection opens in Bruno and a sample of requests matches the original in Insomnia.
Check environments, scripts and authentication
Run each imported collection against its target environments and confirm that variables resolve, scripts run and authentication succeeds. Scripts and auth flows are the most likely places for differences, so test them against a non-production system first. Record each mismatch and its fix in a short checklist. The step is complete when the owner signs off that the key requests return the same responses as in Insomnia.
Commit the collection to Git
Store the Bruno collection in a Git repository on infrastructure your organization controls, so that each collection is a folder of files that can be reviewed, diffed and restored. Keep environment secrets out of committed files, and use the approach your security team has approved for credentials. The step is done when the collection is in the repository, a clean clone opens in Bruno, and the secrets check passes.
Agree conventions for branches and reviews
Decide how the team will name branches, who reviews changes to shared collections, and how collection changes are tied to API changes. Write these conventions into the repository's readme so new members follow them. Bruno's open-source edition supports clone, pull and commit in its Git UI, while push and branch operations are paid features, so agree which Git client each person will use for those actions. The step is done when the conventions are written and the team has tried one full change through review.
Retire Cloud Sync projects after parity
Once the team confirms that the Bruno collections match the Insomnia originals, stop using the Cloud Sync and Git Sync projects and archive the Insomnia exports under the same controls as other records. Confirm with each owner that no active work depends on the old projects before removing any access. The move is complete when every in-scope project has a signed-off Bruno equivalent and the old projects are no longer the source of truth.
Questions teams ask before switching from Insomnia to Bruno
How much effort does moving from Insomnia to Bruno take?
The effort depends mainly on how many collections and environments you have, how many scripts they contain, how authentication is configured, and whether any projects live in Cloud Sync. Bruno imports Postman collections in Collection v2 or v2.1 JSON format, and Insomnia exports can be brought across as well, but each collection still needs a check after import. Teams with a few collections and simple auth usually finish quickly, while large organizations with many shared scripts and token flows need a planned review. Ask your team to count collections, scripts and Cloud Sync projects before estimating anything, and confirm the current Insomnia export options against the latest documentation.
Can our team migrate from Insomnia to Bruno without outside help?
Many teams can do the migration in-house, provided someone takes ownership of the import, the environment check and the Git setup. The main risks are scripts that rely on Insomnia-specific behavior, authentication flows that need reconfiguring, and secrets that must not be committed to a repository. A small pilot on one collection shows how much rework to expect. Teams that need a structured plan, script review or CI wiring can scope that work separately with DeployOpen as a fixed-scope engagement, with deliverables agreed in writing before work starts.
What skills does the team need for a Bruno migration?
Working knowledge of Git is the most important skill, because Bruno stores collections as files in a local folder that teams share through Git. Someone also needs to read and review the JavaScript used in pre-request and test scripts, since Bruno translates common Postman script APIs during import but flags packages such as postman-collection and newman as unsupported. CI work needs someone comfortable with the Bruno CLI, which provides bru run with test reports. Confirm which of these skills exist in your team before you set a schedule.
Does Bruno cover the Insomnia features our team uses?
Bruno covers the core work of building, sending and testing requests, organizing collections and environments, and running them from the command line. Check each Insomnia feature your team relies on, such as Cloud Sync, Git Sync, design tooling, or specific plugins, against Bruno's current documentation. Bruno is offline-only and its README states there are no plans to add cloud sync, so any workflow that depends on a vendor cloud for sharing will need a different process, such as Git. Make a feature inventory first, because that list determines whether Bruno alone is enough.
How are Bruno's paid editions licensed?
Bruno's pricing page lists the Open Source edition at $0, 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. Git push, branch operations, remote connections and merge conflict resolution in the app's Git UI are paid features, while Git still works outside the app on any edition. Paid editions use license keys managed in a license portal that also covers SAML single sign-on and SCIM provisioning. Confirm the current seat count and billing terms on the pricing page before budgeting.
When is a self-hosted Hoppscotch instance a better fit than Bruno?
A self-hosted Hoppscotch instance fits better when people need shared team workspaces with a central server, rather than files passed around through Git. Hoppscotch Community Edition stores team workspaces in a self-hosted PostgreSQL database, so the server is part of your infrastructure and needs installing, upgrading and backing up. Choose it when you want a web-accessible shared workspace inside your own network. Bruno suits teams that want offline collections and Git-based review. Compare the two on who will run the server and how collaboration should work day to day.
Will moving to Bruno keep our API credentials off third-party clouds?
Bruno stores collections as files on the user's filesystem, so collections, including any embedded credentials, stay on devices your organization controls. That is an advantage for teams with data residency or vendor risk concerns. You still need a rule for secrets: avoid committing plaintext tokens to Git, use environment variables or an approved secrets store, and review files before pushing. Confirm how your Insomnia exports handle secrets, because export files can contain them before they reach Bruno.
How DeployOpen helps evaluate and move the team
DeployOpen can run a fixed-scope engagement that takes a team from Insomnia to Bruno in stages, with scope, deliverables and timelines agreed in writing before work starts. The first stage is an inventory of what the team actually uses: which collections, environments, auth settings and pre-request or test scripts exist, which live in Cloud Sync or Git Sync projects, and which sit only on individual laptops. That inventory is the basis for deciding what moves, what gets retired and what needs a second look, and it shows whether the Postman, Insomnia or OpenAPI inputs need separate handling.
The next stage covers storage and Git conventions. DeployOpen can plan the folder layout for the collections repository, branch and review rules, how environment files and secrets are kept out of commits, and how the team will use the Git operations that Bruno's Open Source edition covers compared with the operations its pricing page marks as paid. DeployOpen can migrate the collections and scripts, check imported Postman or Insomnia script behavior against the originals, and run the collections in CI with bru run so results can be compared with the current workflow. Each stage ends with a written record of the results.
DeployOpen does not publish prices. A quote follows from the written scope, so the reader should ask for the inventory size, the number of workspaces and seats, the CI integration, and whether documentation and handover are included as separate line items. Ongoing support, upgrades and continuous testing are available as retainers, which is a separate decision from the one-time migration. Ask the vendor and your own team to confirm current Bruno edition features and per-user prices before the scope is signed, since those can change.
