Six API protocols share one desktop workspace
Insomnia is a cross-platform client for REST, GraphQL, WebSockets, Server-Sent Events, gRPC, and other HTTP-compatible services. A developer can send exploratory requests, inspect responses, edit an OpenAPI document, create test suites, and run collections without moving between several applications. The repository also includes Inso, a command-line tool for linting specifications and running checks in CI. That combination makes most sense for teams whose API work begins interactively and later needs to become repeatable.
Storage is a genuine product choice rather than a cosmetic preference. The README describes a Local Vault for keeping projects on the machine, Git Sync for using a third-party repository, and Cloud Sync for collaborative work. Private Environments stay local regardless of the project storage choice. No-account use is narrower: the local Scratch Pad works without registration, while most project features require an account. Git Sync, unlimited collaboration, organizations, and third-party identity providers sit in paid plans.
The 989 MB source install is much heavier than downloading the app
People evaluating Insomnia should separate using a packaged release from contributing to its source. The normal user route is a download for macOS, Windows, or Linux. Building a development environment means entering a TypeScript monorepo with 2,228 files and roughly 241,962 source lines at the commit we measured. Our clean checkout itself was 23.1 MB, but npm expanded the environment to 989 MB.
The README points contributors to the Node version in .nvmrc, then npm i, linting, type checks, tests, and a live-reload development command. Linux users may need libfontconfig-dev on Debian or libcurl development files on Fedora. It also documents clearing Electron's cache when installation conflicts occur. Those notes are useful, though they leave system preparation partly dependent on the distribution and Electron behavior.
What happened when we ran it
Our sandbox installed 1,750 packages in 72 seconds. The checked-out commit had no root build script or target that the lab could invoke, so the build step was skipped rather than counted as a failure. Vitest completed in 112 seconds with 18 passed and 0 failed. That is a clean result for the tests the target exposed, but 18 tests cannot stand in for every desktop, protocol, sync, and plugin path in a project this broad.
Npm audit reported 39 known vulnerabilities in the installed dependency tree: 2 critical, 13 high, 21 moderate, and 3 low. These are audit findings, not proof that each advisory is reachable through the shipped application. They are still work a team must triage before using this checkout in a controlled build pipeline. The repository has 10 CI workflow files, but our scan found no Dockerfile or conventional tests directory.
All figures above come from our run of commit d9bb2b0 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the lab Node image. We did not measure request latency, desktop memory use, sync reliability, or protocol correctness. The result answers a narrower question: whether the source installs and whether its available test command completes in that environment.
Local storage does not make every feature local
Insomnia's Local Vault and Private Environments give developers useful control over request data and secrets. Git storage can also avoid passing project files through Insomnia Cloud. The account boundary still matters because the README says most capabilities require sign-in even when sensitive projects use local or Git storage. A procurement review should therefore cover both where API data lives and what account services the client contacts.
Open issue 10393 and issue 10412 describe failures fetching organizations in desktop builds. One report shows the application error during login, while another records the organization route failing after a network request. These reports do not establish a universal outage or one cause. They do show why a team relying on cloud workspaces should test offline behavior, login recovery, and access to local projects before standardizing on the client.
Plugins add reach and another trust decision
The plugin hub extends Insomnia beyond its built-in request types and workflows. Release 13.2.0 also included substantial work on plugin sandboxing, capability-aware contexts, action and hook routing, and an opt-in path for elevated access. That activity suggests the boundary between a plugin and the desktop process is being actively tightened, which is welcome, but it also means plugin behavior deserves version-specific testing.
Teams should inventory installed plugins, pin the client release, and remove extensions that no longer have an owner. A plugin can touch request preparation or response handling, which puts credentials and API data near third-party code. The 13.2.0 notes also mention a fix for missing plugins and a change that resolves the QuickJS sandbox engine before plugin code runs. Those are concrete reasons to avoid treating every hub entry as equivalent to a built-in feature.
August 2026 activity is high, while the queue is large
GitHub showed 39,956 stars and 865 combined open issues and pull requests when fetched. The repository was pushed on August 26, 2026, and release 13.2.0 was published one day earlier. The release includes fixes for request history, cloud sync tests, large response downloads, Git credential handling, keyboard focus, and plugin isolation. This is plainly an active project; the combined open count is not a count of confirmed bugs.
Insomnia earns a trial when protocol breadth and storage choice matter. The packaged app is the sensible evaluation path for most users. Source contributors face a different decision: 1,750 packages, 989 MB, no root build target in our harness, and 39 audit findings demand more attention than the successful 18-test run alone suggests.