Migrate from Insomnia to Bruno: what the move involves
If a renewal, Git Sync or Cloud Sync dependence, or a data residency concern is pushing you off Insomnia, the move to Bruno starts with a file export and import, but most of the effort sits in environments, scripts, authentication and retiring Cloud Sync projects. Export each collection from Insomnia as v5 YAML, import it into Bruno, and then check every request against its original behavior. Platform or developer tooling owners usually run this work, with a security reviewer approving where credentials end up, because exported files can carry secrets. Effort scales with the number of collections and the amount of pre-request and test scripting they contain, so start with an inventory of both before you set a cutover date.
Bruno is offline-only, and its README states there are no plans to add cloud sync. Collections are saved as files in a folder on the user's filesystem, so the team's shared source of truth moves from Kong's cloud to a Git repository that your organization hosts. Access control moves with it. Repository permissions, branch protection and review rules take over the job that Insomnia account roles and project membership did, so confirm those controls with your Git host before anyone imports. Bruno's pricing page marks Git push, branch operations and remote connections in the app as paid features, while Git itself works outside the app on any edition. Decide early whether engineers commit from the terminal or whether the team needs a paid edition for in-app Git workflows. The Bruno README sets out the storage model in more detail.
Treat the retirement of Cloud Sync projects as a separate step from the import. Before anyone stops syncing in Insomnia, confirm that every request, environment and secret the team needs exists in the Bruno copy, and keep the Insomnia export as a read-only archive until the suite has run in Bruno through a full release cycle. Environment variables and authentication settings are the most common place for a request to break without an obvious error, so compare them first. Scripts need a line-by-line review, because Bruno's documented script translation covers Postman APIs, and Insomnia scripts may need manual changes. Ask your Bruno contact or check the current import behavior against a sample of your own collections before you commit to a date.
Which Insomnia capabilities map cleanly to Bruno
This table maps each part of an Insomnia workspace to its Bruno equivalent and marks whether it moves cleanly, needs rework or has no direct match. Read the rows before exporting, because Bruno is offline-only and Cloud Sync and account-based sharing become Git workflows. Confirm each import format with a test import before you retire any Cloud Sync project.
| Insomnia capability | Bruno equivalent | Status and what to check |
|---|---|---|
| Collections and folders | Collections stored as a local folder with request files | Needs rework: confirm folder structure and request names survive the v5 YAML or v4 JSON import |
| Requests and bodies | Requests saved as .bru files or OpenCollection YAML | Clean for common HTTP methods: check multipart bodies and file uploads in a test import |
| Environments and variables | Environment files and collection-level variables | Needs rework: recreate secret values locally and confirm variable names resolve after import |
| Auth settings | Per-request and folder-level authentication | Needs rework: re-enter OAuth or token settings and confirm each auth mode is carried over |
| Pre-request and test scripts | Bruno scripts with common Postman-style APIs translated on import | Needs rework: review scripts that use Insomnia-specific APIs or unsupported packages |
| Cloud Sync and account sharing | Git repository holding the collection folder | Gap: no cloud sync is planned, so team sharing moves to Git branches and commits |
| Git Sync projects | Git in the local folder, with Git push and merge conflict tools in paid editions | Needs rework: Git works outside the app on any edition, but push and conflict tools are paid features |
| CLI runs | bru run command with test reports | Clean for scripted runs: confirm reporting output meets your CI requirements before relying on it |
What data to export and what to rebuild
Insomnia migrations split into two groups: what you export as files and what you recreate by hand in Bruno. Knowing the boundary before you start prevents lost requests and leaked credentials. The cards below cover the export paths, the items that do not travel, and the checks to run before any file leaves the app.
Insomnia v5 YAML export
Export collections, projects or all data as Insomnia v5 YAML. This is the format to start from, because it keeps request structure, folders, environments and scripts in a form you can review. Export one project first as a test, then open the result in Bruno and confirm that request counts, folder nesting and environment names match what you see in Insomnia. Note which project each file came from so you can map it to a Git repository later.
HAR export for edge cases
Use HAR export only when a request exists in Insomnia but does not appear cleanly in the YAML export, or when you need a record of recent traffic for debugging. HAR captures request and response pairs, not a reusable collection. Treat it as reference material, then rebuild the requests you need in Bruno. A HAR file often contains headers with tokens, so review it before sharing it.
OpenAPI specs through the inso CLI
If your team designed APIs in Insomnia's design tooling, use the inso CLI to export OpenAPI specifications. Bruno can create collections from OpenAPI, so the spec becomes a second source for endpoints, schemas and examples. Keep the spec in Git as the design record and treat the Bruno collection as the executable layer. Confirm with each import that paths, methods and required parameters match the spec version your consumers use.
Cloud Sync projects and account users
Cloud Sync projects live in Kong's cloud and do not become local files on their own. Before you retire them, export each project you still need, then list the people who had access so you can decide who receives the Bruno collection through Git. Insomnia account users, roles and invitations do not transfer to Bruno, because Bruno has no account-based sharing in the open-source edition. Confirm with Kong that your export covers every project you plan to keep.
Git Sync remotes and plugins
Git Sync remotes point to repositories you already control, so the collection history can usually be preserved by committing the Bruno folder to that repository or a new one. Insomnia plugins have no direct equivalent, so list every plugin in use and rebuild its behavior as Bruno scripts or documented steps. Record the remote URL, branch and any deploy keys so access can be reconfigured without guessing.
Secrets and credentials before export
Environments often hold API keys, bearer tokens and client secrets in plain text. Before any export file leaves the app or reaches a shared drive, search it for keys, tokens and passwords, and move secrets out of collection files. Re-enter them in Bruno's environment handling, keeping sensitive values out of Git. Ask your security team which storage approach they accept for the local machines that will hold these values.
How Bruno imports Insomnia data and where to check it
Treat the import as a hypothesis to test, not a finished migration. After you bring an Insomnia export into Bruno, compare the result against the source project before anyone deletes anything: count the requests in each folder, confirm the folder hierarchy matches, check that every environment has the same variable names and values, and open each request that uses authentication to confirm the auth mode, token source and inherited settings came across. Keep a short checklist per project. Any mismatch is cheaper to find now than after the Insomnia project has been retired. Confirm the exact import behavior for your Insomnia export version in your own environment, since Bruno's import documentation focuses on Postman sources, and note any requests or settings it skips.
Next, decide where the collection will live on disk. Bruno stores each collection as files in a local folder, and that folder is what your team reviews, diffs and commits to Git. Choose between the original .bru plain-text format and OpenCollection YAML, which Bruno supports from version 3.0.0 as an open alternative, and the Bruno documentation describes a migration from .bru to YAML. Pick one format for the whole team before the first commit, because mixing formats across branches makes review harder. Confirm with the Bruno documentation which format your current version writes by default and whether secrets are stored in environment files that should stay out of the repository.
Once the collection is in Git, the same files can run in continuous integration through Bruno's command-line runner, bru run, which can produce test reports. Run the collection in a pipeline against a non-production environment and compare its results with what the team saw in Insomnia, paying attention to scripts, assertions and variables that depend on the app's runtime behavior. Scripts that were written for another client may need adjustment, so confirm each one passes in your environment rather than assuming the import preserved its behavior. Record which Bruno version and CLI version you validated, because the pipeline should pin both.
The migration sequence from inventory to decommission
The sequence moves one collection at a time from Insomnia's cloud-linked projects into Bruno's Git-tracked folders, with each step ending in a check that the team can rely on before the next one starts. The result is a single repository that becomes the source of truth and an Insomnia workspace that no one needs to open.
Inventory projects, environments, scripts and sync links
Before anything is exported, list every Insomnia project and workspace your team uses, and mark which ones sync through Cloud Sync or Git Sync. For each project, note its environments, pre-request and test scripts, and the authentication method on each request, such as OAuth, API keys or bearer tokens. Confirm with the project owners which collections are still in active use, since those are the only ones worth moving. The output is a short register with one row per project and columns for sync type, environment count, script use and auth type, signed off by the team lead.
Pilot one collection in Bruno
Choose a single, low-risk collection that touches a non-production API, then export it from Insomnia as Insomnia v5 YAML and import it into Bruno. Bruno also reads older v4 JSON, so keep the export file even if your Insomnia version differs. Open the imported collection and check that each request sends correctly, that environment variables resolve, and that the Bruno test and script output matches what Insomnia showed. Note every item Bruno could not translate. The pilot is done when one engineer can run the full collection in Bruno against the test environment and the gap list is written down.
Check authentication and secrets in the pilot
Authentication is where migrations most often break, so review it separately from the request bodies. Confirm that OAuth 2 flows, API keys and inherited collection-level auth were carried over, and that no tokens or client secrets were exported in plain text that will be committed to Git. Move credentials into environment files or local secret storage that is excluded from version control. The output is a checklist confirming that each auth method in the register works in Bruno and that no secret appears in the files that will be committed.
Run both clients in parallel
For a defined period agreed by the team, keep the Insomnia project and the Bruno collection running side by side. Engineers send the same requests from each client and compare responses, status codes and test results. Record any mismatch in the gap list and fix it in Bruno before the next collection moves. Bruno's command-line runner, bru run, can execute the collection outside the app, which lets you compare results in a script rather than by hand. The parallel run is complete when the mismatch list is empty for the collections in scope and the team agrees the Bruno results are correct.
Cut over to the Git repository
Commit the Bruno collection folders to a Git repository that your organization controls, then make that repository the only source of truth. Add a short README that explains how to clone the repository, open the folder in Bruno and select the right environment. Ask the team to stop editing the Insomnia project for the migrated collections and to make all changes through commits. Bruno's Open Source edition supports clone, pull and commit in its Git UI, while push and branch operations are paid features, so agree on how changes are pushed before cutover. The output is a repository with a named owner, a branch policy and a confirmed clone on every engineer's machine.
Decommission Insomnia projects and remove sync
Once every collection in scope has cut over, export a final copy of each Insomnia project for your records, then disconnect Cloud Sync and Git Sync and remove the migrated projects from Insomnia. Check that your data retention and records policies allow the export to be stored, and that the exported files are kept in a location your security team controls. Revoke any Kong account access that is no longer needed for these projects. The step is closed when the sync connections are gone, the final exports are archived, and the register shows each project as retired.
Scripts, environments and authentication: what needs rework
Insomnia scripts are JavaScript that runs before a request and after its response. Bruno reads many common Postman script APIs during import, so simple assertions and variable updates often arrive in a usable state. The risk is in what the importer cannot translate. Scripts that depend on external libraries need manual review, because Bruno flags Postman-specific packages such as postman-collection and newman as unsupported rather than running them.
- Check imported assertions: Run each request and confirm the test results match what the Insomnia version reported for the same response.
- Find external imports: Search scripts for require calls and package names, then replace or rewrite each dependency with plain JavaScript or a supported helper.
- Verify chained variables: Scripts that set a value for a later request must still set it in the same order under Bruno's execution model.
- Review error handling: Tests that pass on empty responses can hide breakage, so add checks for status codes and payload shape.
- Record script changes: Keep a list of every rewritten script so reviewers can compare behavior with the original.
Before sign-off, run the full collection once and compare every failing or skipped test with the Insomnia baseline.
Environments hold base URLs, tenant identifiers and secret values that change between development, test and production. Insomnia's environment and secret handling depends on how the project was stored, so the export may carry values in a different structure than the team expects. Confirm which values were exported in plain text, which were masked, and which were never included at all. Bruno keeps collections as files, so any secret written into a file is visible to anyone with access to the folder and to any Git history that receives it.
- Map each environment: Confirm that every Insomnia environment became a Bruno environment with the same variable names.
- Separate secrets from files: Move production tokens and client secrets out of committed files, and reference them through the local environment or the team's secret store.
- Scan the export: Search the exported files for tokens, passwords and keys before the first commit.
- Confirm variable precedence: Test that collection, folder and request variables resolve in the same order as before.
- Ask about secret storage: Check how your organization will distribute secret values to each user's machine, since Bruno does not provide a cloud store for them.
The final check is a clean scan of the repository and a request run against each environment with values supplied only from outside the collection.
Authentication settings are the part most likely to fail silently. A request can return a response that looks valid while using an expired token, a cached credential or the wrong identity provider. OAuth 2.0 flows involve redirect URIs, client registrations, token endpoints and refresh behavior, and the import process does not verify that these settings still work in the new client. Treat each authentication method as a separate test case.
- Test every auth type: Run a request for each method in use, such as bearer tokens, API keys, basic auth, and OAuth 2.0 with authorization code or client credentials.
- Confirm token refresh: Let a token expire or force a refresh, then confirm the request recovers without manual input.
- Check redirect URIs: Verify that the identity provider still accepts the callback settings the new client uses.
- Compare inheritance: Confirm that auth set at the collection or folder level still applies to child requests.
- Review scope: Make sure each flow requests only the scopes the API needs.
Before retiring the Insomnia project, confirm with the API owner and your identity team that each flow was tested with the same credentials and identity provider settings used in production.
What drives the cost and duration of the move
This table lists the factors that set how long the move takes and what it costs, split into one-time work and recurring spend. Read each row against your own Insomnia workspace to estimate scope before asking for a written quote. The main takeaway is that the number of Cloud Sync projects and the complexity of scripts and auth usually matter more than the raw collection count.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Collection count | Each collection needs export, import, and a check that requests still send. Effort grows with the number of collections, not just their size. | Retire unused collections before export and group related requests into fewer collections. |
| Script complexity | Pre-request and test scripts may use Postman-style APIs or packages that need manual rework after import. Unsupported packages are flagged, not converted. | Inventory scripts first and ask the vendor or partner to scope rewrites of unsupported packages separately. |
| Environment count | Each environment's variables, secrets, and overrides must be checked after import, since values can be lost or mapped incorrectly. | Consolidate duplicate environments and remove stale variables before the export. |
| Authentication variety | OAuth 2, API keys, and token flows each need a test against the live service. Mixed schemes add verification time. | List every auth type per collection and confirm credentials are stored outside the shared files. |
| Cloud Sync versus Git Sync dependence | Cloud Sync projects have no file-based copy, so they must be exported before the account is closed. Git Sync projects need a repository, branch rules, and a new team workflow. | Export all Cloud Sync projects and confirm the export files open before retiring them. |
| Team size and onboarding | Each person needs Bruno installed and access to the Git repository. Training time scales with the number of users who edit collections. | Pilot with one team, then document the Git workflow for the rest. |
| CI usage | Pipelines that run collections through the Bruno CLI need new runner configuration, secret injection, and report handling. | Start with a single smoke collection in CI before moving the full suite. |
| Documentation needs | Migration notes, naming conventions, and ownership records take time but are needed for audit evidence and handover. | Reuse the Git README and a short runbook template instead of writing a separate document set. |
| Bruno edition (one-time and recurring) | Open Source is listed at $0 per user per month on Bruno's pricing page. Pro is listed at $6 and Ultimate at $11 per user per month, billed annually, per the same page. Paid Git UI features and bulk Postman import sit in the paid tiers. | Confirm which Git UI operations your team needs. Git still works from the command line on any edition. |
| Git hosting (recurring) | Collections live in a Git repository, so hosting, access control, and backups of that repository are ongoing costs. | Use an existing self-hosted or company Git service and confirm branch protection is available. |
What usually goes wrong and how to prevent it
Most failed moves from Insomnia to Bruno come from the handoff, not the import itself. Secrets travel in export files, teammates lose access when Cloud Sync projects are removed, and the collection ends up with no clear owner. The cards below cover each risk with a check to run before the migration is called finished.
Secrets leaking into exports and Git
An Insomnia export can carry API keys, bearer tokens and passwords stored in environments or auth settings. If that file is saved to a shared drive or committed to a repository, the credentials are exposed to everyone with access and remain in Git history after deletion. Before exporting, review each environment and auth block, move live values into local or secret-scoped environment files, and confirm that .gitignore excludes them before the first commit.
Cloud Sync projects deleted too early
Cloud Sync projects live in Kong's cloud, and removing them or the account that owns them can cut off teammates who have not yet copied their work. Treat Bruno as the new source only after every member confirms that their requests, environments and examples exist in the Git repository. Keep the Insomnia projects read-only for a period you agree in writing with the team, and record who signed off on each one.
Scripts that fail silently after import
Bruno translates common Postman-style script calls during import, but custom helpers, imported packages and assertions written for Insomnia may not behave the same way. A script can produce no error and still skip a check, which makes a test suite look green. Run each request that carries a script, compare its results against the Insomnia output, and add explicit assertions so that a missing value fails the run.
Missing environment variables
Environments, base URLs and secret variables may not all arrive in the same form after conversion, and some requests reference variables that exist only on one developer's machine. The symptom is usually a request that returns 401 or resolves an unexpanded placeholder. Build a list of every variable used in the collection, check each environment in Bruno, and confirm that secret values are supplied by each user rather than stored in the shared files.
Assuming Git UI features are free
Bruno's Open Source edition covers clone, initialize, diffs, pull and commit in its Git UI, but push, branch operations, remote connections and merge conflict resolution are paid features. Git still works from the command line on any edition, so teams can keep working without a license. Decide before cutover which workflow each person will use, and budget for paid seats only if the in-app push and branching features are required, after checking the current Bruno pricing page.
No named owner for the repository
A collection stored as files has no vendor administrator to fall back on. If nobody owns the repository, branch protection, review rules, naming conventions and the shared environment templates drift quickly, and the team stops trusting the collection. Assign one maintainer and a reviewer for changes to shared requests, document who approves environment changes, and record the owner's contact and backup in the repository README.
How the move differs by team size and starting point
A single developer with a few local collections usually has the shortest path. The work is mostly an export of Insomnia v5 YAML, an import into Bruno, and a check of each request that depends on environments or scripts. Because nobody else depends on the collection, the first pass can be done in one sitting and tested against the real endpoints before anything is deleted.
- Export first: Export each collection as Insomnia v5 YAML and keep the files in a separate folder so the originals remain available.
- Import and compare: Import into Bruno, then open several requests and confirm URLs, headers, bodies and auth match the originals.
- Check environments: Recreate base URLs and variables in Bruno environments, and confirm no secret was exported in plain text by mistake.
- Review scripts: Read every pre-request and test script, since Bruno translates common Postman APIs but other logic may need hand edits.
- Store in a folder: Move the collection into a Git repository if you want history, or keep it in a local folder if you do not.
Before you stop using Insomnia, confirm every request you rely on sends the same output in Bruno.
A team that already keeps collections in Git through Insomnia's Git Sync starts closer to the target model, since Bruno also stores collections as files in a folder for Git collaboration. The main change is moving the working copy from Insomnia's Git integration to a Git repository you manage yourself, and agreeing on how branches and reviews work from then on. Git history can usually be carried over, but the team should test that before cutover.
- Choose the repository: Decide whether the existing repository stays as the home of the collection or whether a new layout is cleaner.
- Convert the format: Export the collection, import it into Bruno, and confirm the resulting files are committed in a predictable layout.
- Plan the Git workflow: Confirm which Git operations each team member will run in the terminal and which, if any, they will run in the Bruno Git UI, since some Git UI actions are listed as paid features.
- Coordinate the cutover: Freeze edits in Insomnia for a short window so no changes are lost between the last export and the first Bruno commit.
- Retire Git Sync: Disable Git Sync only after every member has pulled the new layout.
Confirm with each member that their Git client, credentials and branch rules work before the old Git Sync link is removed.
A team relying on Cloud Sync and shared projects has the most work, because the collections, environments and team members live in a Kong account rather than in files the team controls. The migration has to move data out of the account, redistribute it to each person, and decide who owns the new copy. Plan the cutover as a team event, not as individual exports, so no one keeps editing a project that has already been retired.
- Inventory projects: List every Cloud Sync project, its members, and its environments before exporting anything.
- Export per project: Export each project as Insomnia v5 YAML, then verify the files contain the requests the team expects.
- Assign ownership: Name a person or group to own the new shared location, such as a Git repository or a shared folder, and document access rules.
- Rebuild shared environments: Recreate shared environment values in Bruno, keeping secret values out of committed files.
- Retire the project: Stop editing Cloud Sync projects only after all members confirm their copy works.
Ask your Kong account administrator which data remains in the account after you stop using it, and how long you can still export it.
An air-gapped or regulated team has the most constraints on where collections and credentials can sit. Bruno's offline-only model keeps collections in a folder on the user's own filesystem, which suits networks with no vendor cloud access. Any export, transfer and review step must follow the team's own data handling rules, and the migration record should show who approved each step.
- Confirm the data path: Document where exported YAML files move, which media are allowed, and who can read them.
- Scrub credentials: Check each export for embedded tokens and passwords before the files leave the originating machine.
- Verify offline operation: Confirm Bruno runs with no outbound connections required for the collections in use.
- Record the approval: Keep a dated log of the export, import, review and retirement steps for internal audit.
- Plan the CLI runs: If pipelines must run collections, use the Bruno CLI inside the isolated network.
Before approval, ask your security and compliance owners which evidence they need from the migration.
Questions teams ask before migrating from Insomnia to Bruno
How much effort and cost does moving from Insomnia to Bruno involve?
The main cost is staff time, not the client itself, because the Bruno Open Source edition is free to download and use. Effort depends on how many collections, environments and scripts you hold, how many scripts use Postman-specific packages, and how many people need to re-verify requests after import. Recurring cost only appears if you choose a paid edition. Ask for a written scope that lists the collections in scope, the number of users, and whether Git push and branch operations from the app are needed, since those are paid features in Bruno's pricing.
How long does an Insomnia to Bruno migration take?
The duration varies with the size of the estate and how many team members must check the results. A small set of plain requests can be moved in a short working session, while a large workspace with scripts, chained requests and several environments needs time for review and testing. Bruno's documentation covers the import path, but it does not give a timeline for your data. Confirm the duration against your own export, and plan a parallel run where both clients send the same requests until the team agrees the results match.
What does the migration require from our team?
You need someone who can export collections from Insomnia as v5 YAML, someone who can run the import and review the converted requests, and an owner for the repository that will hold the collection. Engineers should review authentication settings, environment variables and scripts, since these are the parts most likely to change during conversion. Security or compliance staff should check that exported files contain no secrets before they are stored in Git. Assign the work to named owners in the project plan before you begin.
Can our own team run this migration without outside help?
Yes, a team with API and Git experience can usually handle a small or medium collection set alone, because Bruno imports Insomnia v5 YAML and also reads older v4 JSON. Outside help becomes more useful when the estate contains many scripts, custom authentication flows, or compliance evidence requirements. DeployOpen plans and implements migrations of self-hosted platforms in your environment under a fixed scope agreed in writing, and it does not publish prices, so ask for a quote based on your written scope.
What happens to our Insomnia Cloud Sync projects?
Cloud Sync projects stay in Kong's cloud and do not move automatically, so you must export them before you change your process. Export the collections and environments you need as Insomnia v5 YAML, verify the files, and store them in a Git repository you control. After the team confirms the export is complete, you can stop using Cloud Sync for those projects. Keep a retained copy of the exports under your own retention policy, and confirm with Kong how long your account data remains available after you leave.
Does Bruno cover the way our CI pipelines run API tests?
Bruno provides a command-line tool, bru, with a bru run command that executes collections and produces test reports, so many CI pipelines can run the same collections without the desktop app. Confirm that your pipelines only use features the CLI supports, such as the scripts and assertions in your collections, and test them in a non-production pipeline first. Check the Bruno CLI documentation for the report formats and the runner options you need, and record the result in your migration plan.
What do the paid Bruno editions add, and what do they cost?
Bruno 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. Open Source is limited to 2 workspaces and 5 OpenAPI syncs per month. Pro and Ultimate add Git UI operations such as push, branch operations, remote connections and merge conflict resolution, while Open Source covers clone, diffs, pull and commit. Ultimate also includes bulk import of a Postman data dump. Paid editions use license keys and add SAML single sign-on and SCIM provisioning. Git still works outside the app on every edition, so ask whether your team needs those features before buying seats.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from Insomnia to Bruno, we start with a written scope that covers which collections, environments and authentication settings move, and where the Git repository will live.
How we scope
- Inventory the Insomnia workspaces, Cloud Sync and Git Sync projects, and environments that need to move.
- Agree in writing which collections move to Bruno and which stay in Insomnia for a defined period.
- Define how Postman-specific scripts and packages are reviewed, rewritten or retired during import.
- Confirm the Git hosting location, branch model and who reviews collection changes before go-live.
How we build
- Export Insomnia v5 YAML, import into Bruno, and record each collection that needed manual correction.
- Check environment variables, secrets and auth settings against the source collections, using test requests.
- Run the Bruno CLI collections in a pipeline to confirm that requests and tests behave as expected.
- Commit the collection folders to Git with a documented layout and contribution steps for the team.
How we hand over
- Deliver a written runbook covering import steps, known gaps, and the Bruno edition chosen for each user.
- Walk the team through the Git workflow, including which Git actions the Open Source edition covers.
- Document the Cloud Sync retirement steps, including what to delete, archive or export before closing projects.
- Provide a checklist for the team to confirm each collection before the old Insomnia projects are retired.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades of Bruno versions and CLI test maintenance are available as a retainer.
- Confirm with DeployOpen the support terms, response expectations and handover owner in the written scope.
- Request a quote based on the written scope, the number of collections and the Git setup your team needs.
