Kong/insomnia: a client for five protocols whose Git Sync sits behind a subscription

Five protocols, nine npm workspaces, and an Electron shell

Insomnia handles GraphQL, REST, WebSockets, Server-Sent Events, gRPC and, in the README's own words, any other HTTP compatible protocol. Around that it does five jobs: debug, design with the native OpenAPI editor and visual preview, test with native test suites and a collection runner, mock through a cloud or self-hosted mocking server, and run lint and test in CI through the native Insomnia CLI, plus third-party plugins from the Plugin Hub.

Underneath it is a monorepo of nine npm workspaces: insomnia, insomnia-testing, insomnia-data, insomnia-vcs, insomnia-analytics, insomnia-api, insomnia-inso, insomnia-smoke-test and insomnia-scripting-environment. The root package is private, versioned 1.0.0, authored by Kong, and licensed Apache-2.0, while the published releases are tagged against a different package, [email protected] on 2026-09-23 and [email protected] on 2026-09-28. So the release line is 13.x and the root manifest says 1.0.0; read the release tag, not the root version, when you pin anything.

Three storage backends, and the Git one is premium

Projects, collections and design specs sit in one of three backends, and they can be combined. Local Vault is 100 percent local storage. Git Sync puts them in any third-party Git repository without going through the cloud. Cloud Sync is cloud collaboration, optionally end-to-end encrypted in the cloud.

The catch is in the premium section. The free plan is described as very generous, but Git Sync is named among the features that need a subscription, alongside unlimited collaboration, the ability to create organizations, and using a third-party identity provider for logins with SAML or OIDC. That single placement reshapes the choice. Local Vault needs no subscription, so a solo developer or a fully offline team is fine on the free plan. A team that wants its requests and environment files reviewed in pull requests is choosing a paid plan, and a team that wants shared cloud collections is choosing one too, because unlimited collaboration is in the same list.

So the open-source client is free and complete as software, and the collaboration layer around it is commercial. Price that before you design the workflow, not after.

Private Environments never leave the machine, whatever backend you use

One feature cuts across the storage question. Private Environments keeps your environment configuration stored locally and never in the cloud, independently of whichever storage backend the project uses. The README is explicit that this holds even when the project itself is on Cloud Sync.

That is the answer to the objection that a cloud-backed client cannot hold a staging token. It can, as long as the value lives in a private environment rather than in the project's shared resources. The practical consequence is a workflow rule rather than a setting: tokens, passwords and per-developer hosts belong in environments marked private, and the shared project carries only the variable names. Anyone on the free plan using Local Vault gets this for the same reason, since there is nothing in the cloud to leak, and the feature exists mainly for the Cloud Sync case.

The account requirement is a business model, and the README says so

There is a section titled Why does Insomnia require an account, and the answer is not a technical one. You can use the local Scratch Pad with no account at all. For most capabilities the project requires one, and the account data is stored in compliance with ISO27001, SOC 2 Type II, ISO27018 and Gold CSA STAR regulations.

The reasoning is stated plainly: the team requires an account to sustainably build and improve the product and to keep offering core capabilities in a free and open-source distribution, because open source software is free to use but not free to build, and continuing work depends on converting a subset of free users into paying customers. That is a candid statement of the arrangement, and it is also the risk to weigh. The Apache-2.0 grant covers the code you can read and build, and the collaboration features that make the product pleasant for a team are the funded part. If your plan depends on Git Sync or shared cloud collections, your dependency is on a company's revenue, not only on a licence.

Two native libcurl builds, pinned to Electron 43.2.0 and Node 24.18.0

The reason a Linux contributor needs a C library and a Windows contributor needs build tools is a native module. package.json carries two node-pre-gyp install scripts for @getinsomnia/node-libcurl, one per runtime:

node-pre-gyp install --directory node_modules/@getinsomnia/node-libcurl --update-binary --runtime=electron --target=43.2.0
node-pre-gyp install --directory node_modules/@getinsomnia/node-libcurl --update-binary --runtime=node --target=24.18.0

Both targets are exact versions, not ranges, which is what a prebuilt binary needs and also what couples the checkout to those two runtimes. The Linux notes follow from it: on Ubuntu or Debian, `sudo apt-get install libfontconfig-dev` after an `sudo apt-get update`, on Fedora `sudo dnf install libcurl-devel`, and if Electron fails during the install process, clear the cache with `rm -rf ~/.cache/electron`. On Windows the README points at the Windows Build Tools. A contributor on a machine with neither a compiler nor a matching prebuilt binary is where this project stops being a `npm i` away from running.

Six commands from the root, and dev is not dev:autoRestart

Development needs Node.js and Git, with the version taken from the `.nvmrc` file and the engines field requiring node >=24.18.0 and npm >=11. The README calls the root commands the only three you need, then lists six:

# Install and Link Dependencies
npm i
# Run Lint
npm run lint
# Run type checking
npm run type-check
# Run Tests
npm test
# Start App with Live Reload
npm run dev
# Start App with both renderer process live reload and main process auto restart
npm run dev:autoRestart

Each maps onto a workspace fan-out rather than a single task: `lint`, `type-check` and `test` all pass `--workspaces --if-present`, so a package without a task is skipped rather than failing. `dev` runs `npm start -w insomnia`, and `dev:autoRestart` switches to the start task that also restarts the main process, which is the one you want when you are changing code in the Electron main process rather than only in the renderer. Editor support matters too: the README asks for ESLint and JSX syntax support, nothing exotic.

Inso is its own workspace with its own compiler

The command line tool is not a mode of the app. It is a separate workspace, insomnia-inso, with its own build path:

npm i
npm run inso-start
./packages/insomnia-inso/bin/inso -v

`inso-start` runs the compiler in watch mode, and the binary is invoked by path rather than installed globally, which is what a CI job wants: a checked-out repository, a build step, and a binary under `packages/insomnia-inso/bin/`. The packaged form is a second script, `inso-package`, which builds and then packages the CLI. This is the piece the README points at for linting and testing collections in a pipeline, and it is also the part that runs without a desktop session, which is why it is worth building separately from the Electron app.

A Nix flake, a patches directory and a plugin sandbox example

The root has more in it than a typical Electron project. There is a `flake.nix` with a `flake.lock`, so a Nix-based development environment is possible alongside the npm route. There is a `patches/` directory and a `build-secure-wrapper.sh` script, which together mean the build is not a straight compile of the checked-in sources. There is a `schemas/` directory, an `examples/insomnia-plugin-sandbox-demo` for the plugin system, and `scripts/` for release work.

The documentation set is split too: `DEVELOPMENT.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `CHANGELOG.md` and a `docs/` directory, plus `.markdownlint.yaml` and `eslint.config.mjs` for the two linters. Two agent instruction files, `AGENTS.md` and `CLAUDE.md`, sit at the root next to them. And `.git-blame-ignore-revs` is present, which is the marker of a repository that has run an automated reformat and would rather not have that commit appear in every blame. All of it says the same thing: this is a company-maintained monorepo, not a solo project, and the cost of that is a contribution process with more steps than the code.

Editorial conclusion

Use Insomnia when one client has to speak GraphQL, REST, WebSockets, SSE and gRPC, and when you are content to keep collections in a Local Vault or pay for Git Sync. Do not adopt it expecting the open-source licence to hand you collaborative storage for free, because the README puts Git Sync, organizations, unlimited collaboration and third-party SAML or OIDC login behind a subscription, while the client itself stays Apache-2.0. Before you commit a team to it, decide where the collections live, keep secrets in Private Environments so they never reach the cloud even on Cloud Sync, and check the runtime coupling in package.json, which pins the native libcurl build to Electron 43.2.0 and Node 24.18.0.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes