Insomnia 8 Data Loss: Recovery Steps and Migration Options

fTL;DR

If you upgraded to Insomnia 8.0 and lost access to your collections, your data is likely still on disk. This guide shows you how to find it, recover it from the SQLite database, and migrate cleanly to Apidog or another alternative. Act before installing any further updates that might overwrite your backup files.

💡

Apidog is a free, all-in-one API development platform. It imports Insomnia collections directly and stores your data locally without requiring an account. Try Apidog free, no credit card required.

button

Introduction

The Insomnia 8.0 update shipped in September 2023 with mandatory cloud login. For many users, the upgrade produced a disorienting result: the application opened to a login screen, and the collections they had built over months or years appeared to be gone.

Some data loss was real – particularly cases where scratch storage corrupted data on certain systems. But in many cases, the underlying SQLite database files were still intact on disk, just inaccessible through the new UI without a Kong account.

This guide is for both situations. If your data is still there, you will find out how to get it out. If scratch storage actually lost your data, you will find out what recovery options exist and how to avoid the same problem going forward by migrating to a tool with a more reliable local-first model.

Step 1: Find your existing Insomnia database files

Before you do anything else – before reinstalling, before creating a Kong account, before opening Insomnia again – locate your existing database files and copy them to a safe location.

Insomnia stored data in different locations depending on the version and operating system.

macOS:

~/Library/Application Support/Insomnia/

Windows:

C:\Users\[Username]\AppData\Roaming\Insomnia\

Linux:

~/.config/Insomnia/

Inside that directory, look for these files:

insomnia.db – the main database (older versions)
A directory called core/ containing .db files – common in versions prior to 8.0
workspaces/ – may contain exported JSON files from earlier exports

Copy the entire Insomnia application support directory to a backup location right now. Do not skip this step. If you run any further upgrades or uninstall/reinstall Insomnia, there is a risk these files get overwritten or deleted.

Step 2: Attempt recovery via the Insomnia UI

If you have not yet logged in to a Kong account, try the scratch storage path first. When Insomnia shows the login screen, look for a link or button that says something like “Use without account” or “Continue with local storage.” The exact wording has changed across versions.

If you can get into the app without logging in, immediately export every workspace:

Click on a workspace name in the left sidebar
Go to the workspace menu (three dots or gear icon)
Choose “Export”
Select “Insomnia v4 (JSON)” format
Save the file somewhere safe
Repeat for every workspace

If you already have a Kong account and can log in, do the same export process. The logged-in experience gives you access to your synced workspaces, which may be more complete than what is on disk if you had been syncing previously.

Step 3: Recover data directly from the SQLite database

If the UI does not give you access to your data, you can extract it directly from the database file. This requires a free SQLite browser tool.

Install DB Browser for SQLite. Download it from sqlitebrowser.org. It is free, open source, and available for macOS, Windows, and Linux.

Open your database file. In DB Browser, go to File > Open Database and navigate to the Insomnia application support directory. Open insomnia.db or any .db file you find there.

Explore the schema. Insomnia’s database has several tables you care about:

Workspace – your top-level workspaces
RequestGroup – folders within workspaces
Request – individual requests
Environment – environment variable sets
Response – stored response history (optional to recover)

Export the data. In the Browse Data tab, select each table and use File > Export > Table as CSV to save the raw data. For requests, the key fields are name, url, method, headers (stored as JSON), and body.

Reconstruct collections. The CSV approach gives you the raw data to rebuild from. It is tedious but reliable. For a programmatic approach, you can use Python’s sqlite3 module to query the database and write an export script.

Here is a minimal Python script to extract requests from an older Insomnia database:

import sqlite3
import json

conn = sqlite3.connect('/path/to/insomnia.db')
cursor = conn.cursor()

cursor.execute("SELECT name, url, method, headers, body FROM Request")
rows = cursor.fetchall()

for row in rows:
    print(f"Name: {row[0]}")
    print(f"Method: {row[2]} {row[1]}")
    if row[3]:
        headers = json.loads(row[3])
        for h in headers:
            print(f"  Header: {h.get('name')}: {h.get('value')}")
    print()

conn.close()

Adjust the field names based on what you see in DB Browser – the exact schema varied across Insomnia versions.

Step 4: Recover from backups if the database is corrupted

If the database file itself is corrupted, options are more limited.

Check Time Machine or system backups. macOS Time Machine, Windows File History, and most cloud backup services (Backblaze, iCloud Drive, etc.) may have snapshots of your Insomnia directory from before the upgrade. Restore the pre-8.0 version of the application support directory to a separate location, then use DB Browser to read those files.

Check git history. Some teams version their Insomnia exports in a git repository. If your organization does this, the export files are recoverable from git history.

Look for Insomnia export files. If you ever manually exported collections in the past, those JSON files may be sitting in your Downloads folder or a project directory. Search your filesystem for files ending in .json that contain “insomnia” or “_collection” in the name.

Step 5: Migrate to Apidog

Once you have your data in Insomnia v4 JSON format (either from a UI export or reconstructed manually), migrating to Apidog takes a few minutes.

Import your collections.

Open Apidog and create a new project
Go to the project settings or the import option in the sidebar
Choose “Import” and select “Insomnia”
Upload your exported JSON file
Apidog will parse the workspaces, folders, requests, and environments

What transfers cleanly:

HTTP requests (GET, POST, PUT, DELETE, PATCH)
Request headers
Request bodies (JSON, form data, multipart)
URL parameters and path variables
Environment variables and their values
Folder structure

What needs manual review:

Pre-request and post-request scripts (JavaScript). Apidog uses a similar scripting model but syntax may need adjustment.
Custom authentication flows that relied on Insomnia plugins
Response test assertions – these need to be re-entered in Apidog’s test format

Set up your environments. After import, check that environment variables imported correctly. Go to the Environments panel and verify base URLs, API keys, and any tokens transferred.

Verify team access. If you are migrating a team workspace, Apidog supports shared workspaces with optional cloud sync. You control whether data syncs to Apidog’s cloud. For teams, enabling sync once is the easiest way to share the migrated collections.

Test a few requests. Pick five or six representative requests from your collection and run them to confirm they work as expected. Pay attention to authentication headers and environment variable substitution.

Avoiding this problem in the future

The core lesson from the Insomnia 8.0 situation is that trusting your critical work data to a single tool without a backup strategy is risky – regardless of which tool you use.

A few habits that protect you going forward:

Export regularly. Schedule a monthly export of your collections to a backup folder or a git repository. This takes two minutes and gives you a recovery path no matter what happens.

Choose local-first tools. Apidog stores data locally by default. Bruno stores collections as plain files on disk. Both let you see and back up your data without relying on a vendor’s cloud.

Check the data model before upgrading. When a major version ships, read the migration notes before updating. If the release changes where or how data is stored, understand the implications before clicking install.

FAQ

Can I recover Insomnia data without logging in to Kong?Yes, if your database files are still on disk. Use DB Browser for SQLite to open the .db file in your Insomnia application support directory and export the data from the tables directly.

What format should I use when exporting Insomnia data?Use Insomnia v4 JSON format. This is the most widely supported format and can be imported by Apidog, Postman, and other tools.

Will my environment variables transfer to Apidog?In most cases yes. Insomnia environments export as part of the v4 JSON format and Apidog imports them. Review the imported environments to confirm values are correct, especially for sensitive tokens.

What is the difference between Insomnia scratch storage and local storage in other tools?Insomnia’s scratch storage was a fallback mode with reliability issues. Apidog and Bruno treat local storage as the primary model, not a fallback. The data is written to disk on every save, not held in memory.

Can I use DB Browser for SQLite on macOS?Yes. DB Browser for SQLite is available for macOS via the project’s website and through Homebrew (brew install db-browser-for-sqlite).

How long does migration from Insomnia to Apidog take?For a typical collection of 50-200 requests, the import takes under five minutes. Reviewing and adjusting scripts and authentication flows can take longer depending on complexity.