Upcoming Breaking Changes

Types of Breaking Change

When we are removing things

  • Deprecation: We are intending to remove this functionality or interface at some future point. We continue to support and maintain it, but recommend that you do not continue to build upon this functionality where possible.
  • Removal: A functionality and/or interface has been removed from Insomnia. Will be posted 90 days before GA, and will be deprecated (see above) well before that if at all possible.

When we are changing things

  • Change Requiring User Action: Will always be posted at least 30 days before GA. Many Insomnia users will need to take some sort of manual action or migration, or will need to adjust their workflows. We strive to avoid these if at all possible. Theoretical example: Completely rebuilding how mock servers work in a non-backwards compatible way.
  • Change That May Require User Action: Will be posted 30 days before GA if we believe there is impact to more then 1% of users. Theoretical example: Adjusting the access plugins have in a way that requires old plugins to be updated.
  • Informational: We'll do our best to post this as early as we can, but commit to no specific timeline. Could be a larger change where we'll automatically migrate and guide users to the new interface/functionality. Could also be a smaller change where we expect very minimal or no user impact. Historical example: Changing tabs to not open by default in 12.4

Upcoming Breaking Changes

Versions not listed here do not have any breaking changes.

v13 - GA June 16, 2026

Plugin Security Hardening

Audience: Insomnia users who install plugins, and plugin authors.

What changed: Insomnia now runs the main application window with nodeIntegration disabled, and runs all plugins in a separate, hidden background window. This is a security hardening change with a small set of breaking changes for some plugins.

Plugins keep their full Node.js access. They now run in a dedicated hidden background window instead of inside the UI. For most plugins, nothing changes and no action is required.

A small number of plugins will break — specifically those that reached directly into the UI/renderer (DOM, window globals, React state, shared in-memory objects) or that returned values that cannot be serialized across a process boundary.

Why: Electron's own security guidelines have long recommended disabling nodeIntegration in renderer processes. We've completed the groundwork to make this feasible without breaking core functionality, and are now enforcing it.

For plugin authors: If your plugin calls Node.js APIs directly from its entry point, it will fail. Plugin execution itself still runs in a Node.js-capable context (a dedicated background process) — if your plugin only uses the insomnia.* plugin API, no changes are needed. If it uses Node.js APIs, those calls need to move into your plugin's execution context rather than any renderer-facing initialization code

How to check: Look for top-level require(...) calls or imports from node:* / fs / path / os etc. in your plugin. If they exist outside of request/response hook bodies, they are likely affected.

Impacted users and plugin authors can learn all the details here.

Templating Tags switched from Nunchuks to LiquidJS

We have upgraded our internal template tags engine to LiquidJS.

Users with advanced syntax in their template tags may need to manually adjust their scripts.

  • Variable assignment: From {% set x = "val" %} to {% assign x = "val" %}.
  • Else-if branch: From {% elif condition %} to {% elsif condition %}.
  • Filter arguments: From {{ s | replace('a','b') }} to {{ s | replace: 'a', 'b' }}.
  • Iterating over object key-value pairs is different between the two engines ({% for k, v in obj %}) to {% for pair in obj %}{{ pair[0] }}/{{ pair[1] }}{% endfor %}) 
  • Nunjucks filter batch, groupby, striptags, nl2br are removed.
  • Other filters may have changed as well. For example, nunjucks uses upper, liquidJS uses upcase

Deprecated Features

  • Unit Tests within a Design Document - Deprecated since 2025. Best practice is using post-response scripts for all tests (you can see a tutorial here). Currently no ETA for when we'll remove the existing functionality.