Insomnia review: pricing, pros and cons

Work is organised into projects, and each project has a storage type. Local Vault keeps all data on the device with no cloud interaction. Cloud Sync stores projects in Insomnia’s cloud with end-to-end encryption, commits, branches and sharing across an organisation. Git Sync stores projects in a third-party Git repository and uses Insomnia as a Git client. A Scratch Pad works offline before you sign in. Storage can be changed after a project is created. Since 13.3, the older Document and Collection types are merged into a single API Collection with Spec and Tests tabs, so an OpenAPI spec and its requests live in one place.

With Git Sync, project resources are written as YAML files and each collaborator clones the repository. From 12.6 the project uses a standard .git folder, after a one-time migration, so the Git command line, GitHub Desktop or an editor’s source control panel work on it directly; from 13.1 the repository can live anywhere on disk and Insomnia reads your ~/.gitconfig. Branch protection is enforced by your Git provider, conflicts open a three-way merge view, and reverts are done with Git tooling outside the app. Insomnia also writes metadata files, so expect occasional changes in the repository when no request has changed.

Requests reference environment variables and template tags with double braces. In version 13 the template engine moved from Nunjucks to LiquidJS, so the syntax inside tags follows Liquid: assign instead of set, elsif instead of elif, and colon-separated filter arguments. Scripts run before a request and after its response through the insomnia object, which reads and sets variables at environment, base environment and local scope, edits the outgoing request, sends extra requests and asserts with insomnia.test and insomnia.expect. Scripts can require bundled libraries such as ajv, chai, lodash and uuid, plus a set of Node.js modules.

Inso is the command line companion, distributed with each Insomnia release for macOS, Windows and Linux and as the kong/inso Docker image. It looks for data in a .insomnia directory in the working directory, in the Insomnia app data directory, or in a file passed with --workingDir, which can be an export or a Git Sync YAML file. inso run collection runs requests and their scripts with environments, iteration data and environment overrides; inso lint spec checks OpenAPI documents; and inso run test runs legacy unit tests. The --ci flag disables prompts so CI jobs fail cleanly on a non-zero exit code.

Decide storage per project before anyone builds a large collection. For API tests that should be reviewed with the code, use Git Sync and give the Insomnia project its own folder or repository, since Insomnia manages the file layout and its metadata. Keep one API Collection per service, with folders by resource, a base environment holding defaults and one environment per target. Keep secrets out of synced environments: use a private environment, an external vault on Enterprise, or values passed to Inso with --env-var in CI. Agree that folder moves and structural changes are made with Git tooling, because Insomnia does not change project structure from its interface.

Request chaining is where scripts earn their place. A pre-request script can call insomnia.sendRequest, awaited through a promise as Kong’s examples show, to fetch a token or create test data, store the result in an environment variable and let the main request use it. After-response scripts then assert and pass ids forward. Keep chained flows short and explicit, and name variables for their purpose, because a long chain of implicit environment writes is hard to debug when one link fails. For reusable logic, Insomnia’s folder-level variables and parent folder access let a folder hold shared values for every request inside it.

Download the Inso binary that matches your Insomnia version from the GitHub release, check out the Git Sync repository, and run inso run collection with --ci so prompts are disabled and failures set the exit code. Point --workingDir at the collection’s YAML file or an export, select the environment by name, and inject secrets with --env-var. Inso has console reporters such as spec, dot and tap, and --output writes results to a JSON file, which you can upload as an artefact or convert for your dashboard; it does not write JUnit XML itself. Kong also maintains a setup-inso action, whose documented examples pin older Inso versions.

Plan the upgrade as three checks. First, templates: search requests and environments for Nunjucks constructs such as set, elif, filter calls with parentheses and object iteration, and rewrite them in Liquid syntax. Second, plugins: plugins now run in a separate background window without direct access to the renderer, so plugins that touch the DOM, window globals or React state break, and plugins that call Node.js APIs from their entry point fail. Third, tests: 13.3 hides legacy unit tests by default and Kong plans to deprecate them, so move assertions into after-response scripts. Upgrade one person first, and coordinate the team on Git Sync so everyone moves together.