Leaving Insomnia? Make the repo the source of truth.

It depends which half of Insomnia you use. If you use it as a local API client and keep the results in Git, Bandura is built for that case and goes further: the .aether file is the format rather than something a sync layer writes, the graph and the code editor are two renderings of it, and ten node types cover branching, loops, parallel fan-out and subflows without a script. If you use Insomnia's cloud projects, its design and governance tooling, or its plugin ecosystem, Bandura does not replace those and is not trying to.

No, and it would be dishonest to imply otherwise. Insomnia 8.0 in September 2023 pushed everyone toward an account and cloud storage, which caused enough of a reaction that Kong shipped local-only projects again in 8.3 later that year; their own release post is titled around bringing local projects back. What is still true as of August 2026 is the shape of the product: cloud is one of three storage modes the vendor controls, the free Essentials tier limits Git Sync to three users, and the plans above it are $12 and $45 per user per month. Bandura has nothing to log into because there is no server on our side to log into.

Insomnia's Git Sync is a Git client inside the app that mirrors a project into a repository as YAML, plus metadata it writes to support application features. Kong's docs also note you cannot change the project structure from Insomnia's interface, only through Git tooling. Bandura skips the mirroring step: a flow is one .aether file that you put wherever you want in your repo, and the app reads it from disk. There is no store to sync from, so there is no sync commit, no structure the app owns, and no tier that decides how many people may use Git.

Yes, and both halves in one pass, because Insomnia keeps requests and environments in the same export. Export via Application → Preferences → Data → Export Data → Insomnia v4 (JSON), drop the file on the window, and read the review step before anything is written: the detected format, each flow with its node count, the environment variables found, checkboxes, and an editable destination folder. Requests become one .aether flow each with a status assertion; environment values land in your .env with their names recorded in the manifest. Method, URL, headers, JSON and form bodies, path and query params, and bearer/basic auth come across. GraphQL bodies, gRPC and WebSocket requests, pre-request scripts and OAuth flows are skipped rather than half-imported.

The same set: REST/HTTP, GraphQL, gRPC (unary and server-streaming, from a .proto file or server reflection), WebSocket, and Server-Sent Events. This is not a differentiator in either direction, and a comparison table that pretended otherwise would be wrong. The difference is what happens around a request: assertions, capture, branching, loops, parallel fan-out, subflows and retry/poll-until are node types in the file, not code you write and maintain.

Keys go in your operating system's encrypted secret store (macOS Keychain, Windows DPAPI, libsecret on Linux) and never into a flow file or into settings. Flow-level secrets are env.* references read from your environment or a .env you do not commit. Preferences live in a hand-editable settings.json on your disk, comments allowed, with the licence key held separately so editing settings cannot invalidate it. None of it syncs anywhere, because there is nowhere for it to sync to.

Bandura is free indefinitely for personal projects, learning, and open source. Commercial use is a one-time per-seat licence after a 30-day evaluation that disables nothing, priced when checkout opens at launch, covering every release built in the following 12 months, after which the build you have keeps working. Nothing auto-renews. Insomnia, as of August 2026, is free on Essentials with Git Sync capped at three users, then $12 per user per month on Pro and $45 on Enterprise, billed annually: $720 a year for a five-person team on Pro, recurring, against one payment per seat on Bandura.

Into one of two places, and the import names which requests carried a script rather than half-converting it. Cross-cutting work (signing, a correlation id, an audit line) belongs in the flow's hooks block, whose before, after and onError phases run around every request-like node, so one hook covers the whole flow instead of being pasted into each request. Anything specific to one step is a script node in the flow, and a hook or a script body can live in its own .js file that several flows point at, so a signing routine is written once. Both are plain JavaScript in the same scope, with a log() binding that writes to the run console.