Insomnia release and versioning policy

Insomnia uses semantic versioning, a three-part number format: MAJOR.MINOR.PATCH (for example 2.5.1) for defining versions.

Insomnia communicates all changes via:

• A changelog.

• The GitHub releases page.

Public documentation updates support the latest versions of Insomnia.

• Generally Available (GA): Released to all users.
• Beta: A 7-day period before GA when users can opt in to test the release and provide early feedback. Opt in via Settings > Release Channel in the Insomnia app.
• Preview or Tech Preview: Features that are ready to use but still in active development. Preview features are clearly marked in the product.

Learn more about stages of software availability on the dedicated page.

Insomnia strongly recommends using the newest version, and that all users collaborating on the same project remain on the same major version.

Insomnia doesn’t have an explicit Long Term Support (LTS) policy, nor does it publish LTS versions.

Fixes and changes don’t backport to earlier versions. The best practice is to upgrade to the latest version.

Insomnia ships a major version when the release contains breaking changes. Breaking changes count as anything that could cause an existing workflow, configuration, or integration to stop working after the upgrade.

For example:

• Removing a request type, protocol, or authentication method.
• Removing or renaming a CLI command, flag, or subcommand.
• Changing the export schema for collections or environments in a way that older versions can’t read.
• Dropping support for an operating system, platform, or runtime.
• Changing the plugin API in a way that breaks existing plugins.
• Removing or renaming a public API endpoint.
• Changing the default behavior of a feature in a way that affects existing users.
• Migrating the underlying data store to a format that can’t be incompatible with prior versions.
• Removing a UI panel, tab, or workflow that users actively rely on.

Insomnia ships a minor version when a release adds new functionality that’s fully backwards-compatible with the previous version.

For example:

• Adding a new request type, protocol, or authentication method.
• Adding a new CLI command, flag, or subcommand.
• Introducing a new UI panel, tab, or workflow.
• Adding new fields or options to the collection or environment export format, without changing existing fields.
• Adding a new plugin hook, or extending the plugin API in a way that doesn’t break existing plugins.
• Adding support for a new operating system or platform.
• Deprecating a feature, command, or API without removing it.
• Adding new environment variable types or template tag functions.
• Adding a new integration, such as a Git provider or CI/CD tool.
• Adding new configuration options or preferences.

Insomnia ships a patch version when a release contains only backwards-compatible bug fixes, corrections that make Insomnia behave the way it was already documented or intended to behave.

Examples include:

• Fixing a crash or hang during request execution.
• Correcting response rendering or syntax highlighting errors.
• Fixing import or export errors that prevented valid collections from loading.
• Fixing authentication flows that didn’t complete correctly.
• Fixing environment variable resolution or template tag evaluation.
• Correcting UI rendering glitches or layout issues.
• Resolving sync or collaboration conflicts, including data loss scenarios.
• Patching security vulnerabilities in bundled dependencies, with no user-facing behavior change.
• Fixing incorrect HTTP header handling or encoding.
• Correcting documentation links or in-app help text.

Users can provide feedback depending on the type of plan they are on: