Migrate from Insomnia to Hoppscotch

Migrate from Insomnia to Hoppscotch: what the move involves

A renewal, a Kong account requirement or a data residency concern is usually what pushes a team toward a self-hosted Hoppscotch instance. The move is a collection, environment and access migration, and it also means running a server that someone must install, patch and back up. The work is usually led by the platform or IT team, with a security owner signing off on where collections, credentials and team accounts will live. The Community Edition is MIT licensed and free to use, so the main cost is the infrastructure and staff time to run it, not a license fee. Confirm the exact license terms in the Hoppscotch LICENSE file before you approve the plan.

Effort depends mostly on how much Insomnia content your team has and how much of it is tied to Kong's cloud features. Plan the work in three parts: export collections and environments from Insomnia, import them into Hoppscotch through its Insomnia importer, and then recreate workspaces, members and sign-in settings on the new server. Hoppscotch's importer accepts Insomnia collections and environments, but self-hosted editions cap an import at 50 MB, so split very large exports before you start. Check every imported environment for secrets, since those values will sit in your own database once imported. The main risk is credentials and tokens that move with the collections, so decide in advance which secrets get rotated instead of copied.

Before you go live, decide how the team will sign in. Community Edition supports Email, GitHub, Google and Microsoft OAuth providers configured by your administrator and needs SMTP settings for email. Confirm which of these your identity provider can support, and whether SAML SSO, SCIM provisioning or audit logs are needed, since those belong to the Enterprise Edition. Ask your implementation partner or Hoppscotch to confirm current requirements for your version, and test a pilot workspace with a small group before moving the whole organization. Keep the Insomnia export and a rollback plan until the team has verified every collection, because the old account may stop being usable once renewal or cancellation takes effect.

Which Insomnia capabilities map to Hoppscotch and where the gaps are

This table maps each Insomnia capability your team uses to its closest self-hosted Hoppscotch equivalent and marks it as clean, needs rework or gap. Read the rows against your own collections, because a row marked clean still needs a test run on your real requests. The main takeaway is that Community Edition covers core collection work, but SAML SSO and SCIM need Enterprise Edition and Insomnia Git Sync has no direct replacement.

Insomnia capability	Hoppscotch equivalent	Status and notes
Collections and folders	Collections in a Hoppscotch workspace, imported from Insomnia	Clean. Confirm nested folders and request order survive import on a sample export.
Environments and variables	Environments imported with collections, selected per request	Needs rework. Check variable scope and secret values, which must be re-entered or reviewed after import.
Requests and protocol coverage	REST, GraphQL and other request types supported by Hoppscotch	Needs rework. Confirm protocol coverage, such as gRPC, WebSocket or SSE, against your own requests before retiring Insomnia.
Pre-request and test scripts	Hoppscotch scripting with its own JavaScript API	Needs rework. Scripts are not guaranteed to run unchanged. Rewrite and retest each one.
Authentication settings	Auth configuration per request, collection or environment	Needs rework. Re-enter OAuth clients and tokens, and confirm imported auth types map correctly.
Workspaces and team sharing	Team workspaces stored in your self-hosted PostgreSQL database	Needs rework. Recreate workspaces and invite members manually, since organization structure does not carry over.
Git-based sync	No direct equivalent in Hoppscotch	Gap. Insomnia Git Sync has no direct Hoppscotch equivalent, so plan a separate file or Git process for versioned collections.
CI test runs	hopp test from the Hoppscotch CLI, with JUnit XML reports	Needs rework. The CLI is alpha, so pin a version and confirm your test assertions run as expected.
Sign-in for the team	Email, GitHub, Google or Microsoft OAuth in Community Edition. SAML SSO and SCIM require Enterprise Edition	Gap. Community Edition has no SAML SSO or SCIM, so confirm whether your identity provider model needs Enterprise Edition.

What data moves, what identities change and which integrations to rebuild

Moving from Insomnia to Hoppscotch touches three things: the collections and environments themselves, the people who sign in and the test runs that depend on those collections. Each card below covers one of these, with the checks to make before the old Insomnia workspace is retired.

Exporting collections and environments

Start by exporting collections and environments from each Insomnia project using a documented export path, either Insomnia v5 YAML or HAR. Check each file for stored credentials, tokens and API keys before it leaves your device, because those values travel with the export. Keep the export in a restricted location and record which projects were exported and when, so the import can be verified against the source. For OpenAPI specifications, the inso CLI route is covered on the export page.

Importing through the Insomnia importer

Hoppscotch's importer accepts Insomnia collections and environments and creates them in the target workspace. The self-hosted import limit is 50 MB, which is five times the 10 MB limit on Hoppscotch Cloud, so large Insomnia exports are more likely to fit on your own server. Split any export that exceeds the limit by project, import each part, and compare request counts and environment variables against the source before you treat the import as complete.

Recreating workspaces and members

Hoppscotch does not carry over Insomnia's Kong cloud organizations, projects or members, so workspaces and access must be rebuilt on your instance. Map each Insomnia project to a Hoppscotch workspace, decide which team members need edit rights and which need read access, and assign roles by group rather than one user at a time where your edition allows it. Confirm the role model with Hoppscotch for your edition before the migration plan is final.

Sign-in through Email, GitHub, Google or Microsoft

Community Edition signs users in through Email, GitHub, Google or Microsoft OAuth providers that your administrator configures on the server. Each provider needs its own client registration and redirect settings, and you must decide which providers your team may use before inviting anyone. Email sign-in also depends on SMTP settings for verification and invitation messages. Test each sign-in path with a pilot user before cutover, and note that SAML, OpenID Connect and SCIM belong to the Enterprise Edition, which you should confirm with Hoppscotch for your identity provider.

Configuring SMTP for invitations

Email is both a sign-in method and the channel for workspace invitations, password resets and notifications on a self-hosted instance. Your team must supply an SMTP relay that the Hoppscotch containers can reach, along with a sender address that your mail policy accepts. Without working SMTP, invitations fail silently for new members. Confirm the SMTP variables with the install documentation for your release and send a test invitation to a pilot account before you rely on it.

Rebuilding CI runs with hopp test

Insomnia test runs in CI, if you use them, must be rebuilt with the Hoppscotch CLI, which is installed from npm as @hoppscotch/cli and is described as alpha. Run hopp test against an exported collection file or against your self-hosted instance, and write JUnit XML reports so your pipeline can read the results. Current versions need Node.js 22 or later. Because the CLI is alpha, pin the version in your pipeline and confirm which features your tests rely on.

The migration sequence from inventory to decommission

This sequence moves an Insomnia organization to a self-hosted Hoppscotch instance in stages, so each step produces a checked artifact and the team keeps working in Insomnia until the new instance is proven. Each stage ends with a record you can hand to security, compliance or the platform owner.

Inventory workspaces, collections, environments and secrets
List every Insomnia workspace, project, collection, environment and stored credential, and note which team members own or use each one. Record where each project lives today, including any Cloud Sync or Git Sync projects, because the storage model affects how you export. The owner of each workspace signs off on the list. Done means you have a written inventory with one row per collection and a marked flag for every environment that contains secrets, so nothing is moved by accident.
Export collections and environments as archives
Export each collection and environment from Insomnia in a format Hoppscotch can read, and store the files in an access-controlled location on infrastructure you control. Review exported environments for embedded tokens and passwords before they leave the source tool, and decide which values are re-entered by hand. Done means every inventory row has a matching archived file and the archive is checksummed and stored with the inventory.
Run a pilot import into a non-production instance
Stand up a non-production Hoppscotch Community Edition instance and import a representative subset of collections and environments with the Insomnia importer. Check the import size limit on self-hosted editions, which the importer documentation sets at 50 MB, and split larger exports. Compare request counts, headers, auth settings and scripts against the originals. Done means a validated import report lists what matched, what needed manual rework, and what the importer dropped.
Re-test imported requests against the same targets
Run the imported collections against the same API environments used in Insomnia, first from the Hoppscotch interface and then with the Hoppscotch CLI, which can write JUnit XML reports for your pipeline. The CLI is labeled alpha, so confirm its behavior with your own test suites before depending on it. Done means a signed-off test run shows the same pass and fail results as Insomnia for the pilot set, with any differences explained and fixed.
Run both tools in parallel
Keep Insomnia in use for live work while the pilot collections and new requests are maintained in Hoppscotch on the production instance. Set a rule for which tool is the source of truth for each collection, and log any change made in one tool so it is copied to the other. Confirm that sign-in works for every team member through the providers your administrator configured. Done means the parallel period closes with a list of collections that have no open discrepancies and a named owner for each.
Cut over workspaces and members
Create the production workspaces in Hoppscotch, recreate membership and roles from the inventory, and import the final collection and environment archives. Freeze edits in Insomnia for each workspace before its final import, then confirm that the imported counts match the frozen source. Done means every workspace has its agreed members, the inventory shows each collection as migrated, and the team confirms access in writing.
Decommission the Insomnia organization
Remove team members from the Insomnia organization, revoke any API tokens and credentials that were stored there, and keep the signed archives and the inventory under your retention policy. Cancel or downgrade paid seats only after the billing owner confirms the final export. Done means the Insomnia organization has no active users or live secrets, the archive is stored where your records team can find it, and the decommission record is signed by the platform owner.

How the self-hosted Hoppscotch instance is built and where it runs

The Community Edition is packaged as Docker containers, either as separate frontend, backend and admin images or as one all-in-one container, and Hoppscotch also documents a Helm chart for Kubernetes. Pick the packaging before the migration starts, because it determines how the team deploys, upgrades and backs up the instance. Every workspace, collection and environment you import lands in PostgreSQL, which the instance reaches through the DATABASE_URL setting. Confirm with your database team which PostgreSQL version, backup schedule and high-availability design they will support, and make sure the import happens in a staging copy before it touches production data.

Building the application image is the heavier step. Hoppscotch's prerequisites list 4 CPU cores and 4 GB of RAM to generate the build image, and as little as 1 CPU core and 2 GB of RAM to host the output. Those figures come from Hoppscotch's prerequisites page and should be checked against the version you deploy, since requirements change between releases. Build on a host you control, and follow the steps in the install and build guide rather than improvising the sequence.

Where the instance runs decides who holds the data. Collections, environments and any credentials saved inside them, such as bearer tokens or API keys, sit in the database and the hosts you operate, inside your cloud account, data center or isolated network. Restrict database access, encrypt backups, and set retention on logs that might capture request headers. Ask your security team to review which secrets were stored in Insomnia environments before the import, because an import carries those values into the new system.

How the migration changes by team size and starting point

A small team on Insomnia's free or single-user setup usually has a handful of workspaces, a few environments and little shared governance. In this case the migration is mostly an export and import exercise, and the main new work is standing up one Hoppscotch Community Edition instance that the team can reach. The illustrative example below assumes three people and two projects.

Export first: Export each collection and its environments from Insomnia as Insomnia v5 YAML, then confirm that the files open correctly before deleting anything in the app.
Import into Hoppscotch: Use the Insomnia importer in Hoppscotch, which accepts collections and environments, and check each request, header and variable against the original.
Keep the server small: Community Edition runs as Docker containers backed by PostgreSQL, so one modest host and a database are often enough for a few users.
Choose a simple sign-in: Email, GitHub, Google or Microsoft OAuth can be configured without the Enterprise license, and SMTP is needed if you use email sign-in.
Remove secrets from exports: Check exported files for embedded tokens before sharing them with the team.

Confirm that every stored credential was re-entered or rotated on the new instance before you retire the Insomnia copy.

What drives the cost and duration of the Hoppscotch migration

This table breaks down who pays for each part of a self-hosted Hoppscotch migration, separates one-time migration work from recurring operation, and names the inputs that push effort up. Read it as a checklist for building a written quote, since most of the cost sits in staff time and hosting rather than in the software license.

Cost component	Who pays and how	One-time or recurring	What drives it up
Software licence	Community Edition is free to use. Enterprise Edition requires a license key and is priced per user by Hoppscotch, so confirm the current rate directly with the vendor.	Recurring for Enterprise, none for Community	Number of named users and whether SAML SSO, SCIM and audit logs are required
Hosting and runtime	Your cloud account or data center pays for the frontend, backend, admin containers and the PostgreSQL database set through DATABASE_URL. The docs list minimum build and host CPU and memory.	Recurring	Team size, number of concurrent users, and the build host used for the image
Migration inventory and cleanup	Your staff or your implementation partner reviews each Insomnia workspace, removes stale requests and moves secrets out of collection files before import.	One-time	Number of workspaces, duplicated folders, and embedded tokens or passwords in environments
Import and validation	Your team runs the Insomnia importer, checks that environments, auth and scripts carried over, and runs a sample of requests against test endpoints.	One-time	Import size against the 50 MB self-hosted limit, and the number of environments per workspace
Sign-in and identity setup	Your identity team configures Email, GitHub, Google or Microsoft OAuth and the SMTP settings required for email. Choosing an identity provider you already run usually shortens this work.	One-time, then recurring for account changes	Choice of identity provider, existing SSO integration, and whether group mapping is required
CI pipeline rebuild	Your platform engineers replace any Insomnia-based test runs with the Hoppscotch CLI (hopp test) and wire JUnit XML reports into the pipeline. The CLI is described as alpha.	One-time	Number of pipelines that run collections and the test reporting your CI already expects
Upgrades, backups and monitoring	Your operations team applies quarterly Community Edition releases, takes database backups, and monitors the instance. Community support is through the community forum.	Recurring	Release testing effort, database size, and whether an external support retainer covers upgrades
Quote request	Ask the implementer for a written scope listing workspaces, users, import size, identity provider, pipelines to rebuild, hosting assumptions and who performs each upgrade and backup.	Once, at procurement	Unclear scope, which is the most common reason estimates change after kickoff

What usually goes wrong and how to prevent it

Most failed Insomnia to Hoppscotch moves break at the edges: the import itself, the secrets inside exported files, the sign-in setup and the handover to automated tests. Each card below names one failure point and the check that prevents it, so the cutover can be verified before users depend on the new instance.

Imports above the self-hosted limit

Hoppscotch's importer accepts collections and environments from Insomnia, but the self-hosted limit is 50 MB per import. Large workspaces with many recorded responses, file uploads or embedded specifications can exceed it. Before importing, check the size of each exported file, split oversized workspaces by folder or project, and strip recorded response bodies you do not need. Confirm the import succeeded by comparing request counts against the source.

Secrets left in exported files

Insomnia exports can carry API keys, bearer tokens and passwords inside requests, auth settings and environment values. Those files then sit on laptops, in tickets and in shared drives during the move. Before exporting, review which environments hold live credentials and move them to a secrets store or to Hoppscotch environment variables marked as secret. Delete every exported file once the import is verified, and record who handled them.

Environment variables that do not carry over

Variables such as base URLs, tenant IDs and per-environment overrides may import with different names, scopes or secret flags than the source workspace used. Requests then fail silently against the wrong host or with empty headers. Build a list of every variable each environment defines in Insomnia, then open the imported Hoppscotch environment and confirm each value resolves for a test request in dev, staging and production.

Scripts that assume Insomnia behavior

Pre-request and test scripts written for Insomnia may call helpers, object paths or response methods that Hoppscotch handles differently or does not provide. A script can run without error and still assert nothing. Read every script in the migrated collections, rewrite the Insomnia-specific calls, and run each request that has a test to confirm it fails when the expected value is wrong.

Invitations fail without SMTP

The Community Edition signs users in through Email, GitHub, Google or Microsoft OAuth providers, and email sign-in and invitations depend on SMTP settings that the administrator configures. Without working SMTP, new members never receive invitations and the team cannot finish onboarding. Before inviting anyone, send a test sign-in email from the instance to a mailbox outside the team, and confirm the message arrives and the link works.

OAuth redirect misconfiguration

Each OAuth provider needs a redirect URL that matches the public address of your Hoppscotch instance exactly, including scheme, host and path. A mismatch causes sign-in to loop or fail for everyone at once, often after a DNS or reverse proxy change. Register the callback URLs with each identity provider before cutover, test sign-in from a clean browser session, and keep the provider settings in your change record.

Members and roles not re-invited

Insomnia organization members, roles and workspace access do not move as-is into a self-hosted Hoppscotch instance. Teams that import collections but skip the invitation step end up with orphaned content that nobody can open. Build a member list from the Insomnia organization, recreate each team workspace, invite each person with the role they need, and confirm each member can open the shared collections before the old workspace is closed.

Cutover before CI uses the CLI

Teams often switch daily work to Hoppscotch while their pipelines still call the old tooling, which breaks builds when the source is retired. The Hoppscotch CLI, installed as the alpha package @hoppscotch/cli, runs collections with hopp test and can write JUnit XML reports, and it needs Node.js 22 or later. Point a pipeline job at the migrated collections, check the JUnit output, and keep the old job running until the new one passes on a real branch.

Questions buyers ask before moving from Insomnia to Hoppscotch

What does a move from Insomnia to Hoppscotch cost, and what drives it?

The cost comes from people and infrastructure, not from a Hoppscotch license. Community Edition is free and open source under the MIT License, so the one-time costs are the work to export, import, recreate workspaces and set up sign-in, plus the servers and PostgreSQL database you run. Recurring costs are hosting, upgrades, backups and support time. The Hoppscotch documentation lists the minimum build resources as 4 CPU cores and 4 GB of RAM, and 1 CPU core and 2 GB of RAM to host the output. Costs rise with the number of collections, environments and users, and with how much of the team needs Enterprise features. Ask any implementation partner for a fixed-scope quote in writing that lists the inventory, deliverables and what is excluded.

How long does an Insomnia to Hoppscotch migration take?

Duration depends on the inventory more than on the tool. The number of workspaces, collections, environments, scripts, authentication settings and team members decides how much checking and recreation is needed. Before estimating, count each item and note which ones use Insomnia-specific features that the importer may not carry over unchanged. Check the import size limit as well: Hoppscotch's importer documentation sets it at 50 MB for self-hosted editions, so very large exports may need splitting. Ask for a timeline that is tied to that inventory and to a named set of deliverables.

What does our team need to provide for the migration?

Plan to supply access to the Insomnia organization, an export from each workspace or project, and the people who own each collection so they can confirm that requests still behave correctly. You will also need a server or Kubernetes environment inside your own infrastructure, a PostgreSQL database reachable through the DATABASE_URL setting, an SMTP service for email sign-in, and the OAuth client details for any identity providers you plan to use. Decide who approves credentials, since exports can contain secrets. Name a technical owner who can handle DNS, certificates and the upgrade calendar after go-live.

Can our internal team migrate from Insomnia to Hoppscotch without outside help?

Yes, a team with container and database experience can do it alone, and the Hoppscotch install and importer documentation are a usable starting point. The main risks are not technical installation. They are missed environment variables, scripts that depend on Insomnia behavior, credentials left in exports and inconsistent workspace membership. A small pilot with one real collection will show these gaps early. If your team has no spare capacity, a fixed-scope engagement from DeployOpen can plan, implement, harden, back up and document the instance inside your infrastructure, with the scope agreed in writing first.

Is Hoppscotch Community Edition enough for single sign-on?

Community Edition supports sign-in with Email, GitHub, Google and Microsoft OAuth providers that the administrator configures, and it needs SMTP settings for email. That covers many teams, but it does not include SAML-based SSO, OpenID Connect as listed for Enterprise, SCIM provisioning or audit logs. Hoppscotch's documentation places SAML SSO, SCIM, activity and audit logs and user groups in the Enterprise Edition, which requires a license key. Confirm with Hoppscotch which sign-in method your identity provider needs and whether your compliance evidence depends on audit logs before you choose the edition.

What happens to our data during a parallel run?

During a parallel run, Insomnia and Hoppscotch both hold copies of the same collections, so the rule is to decide one source of truth per collection and record when it changes. Freeze edits to migrated collections in Insomnia or agree a cutover date, then compare request results and environment variables in both tools. Keep the Insomnia export files under the same access controls as your other secrets, and delete them when the cutover is signed off. Remember that Insomnia Cloud Sync projects remain in Kong's cloud until you remove them, so confirm their status as part of retirement.

What does DeployOpen cover, and what does it not issue?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted Hoppscotch inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. DeployOpen can also prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.

Official sources for the migration

The sources below cover the Hoppscotch importer, self-hosting, install and deploy steps, prerequisites, the CLI and the license. Read them together before you export anything from Insomnia, because the importer limit, the database requirement and the sign-in setup all shape how you plan the move.

Hoppscotch importer documentation

This page lists the Insomnia collections and environments the importer accepts and the import size limit for self-hosted editions. Check the limit against your largest Insomnia export before you start, and split any larger export into smaller files. Confirm with a test export from a non-production workspace how environments, auth settings and scripts arrive, because you will need to rebuild anything the importer drops.

Self-hosting getting started guide

This is the entry point for running Hoppscotch on your own infrastructure and explains the difference between the Community and Enterprise editions. Use it to decide which edition fits your sign-in and support needs before you commit to a deployment. Note that the Community Edition is installed, administered and updated by your team.

Community Edition install and deploy docs

These pages describe how to build and deploy Community Edition with Docker containers, including the all-in-one option and the Helm chart for Kubernetes. Choose the packaging that matches your platform team's existing operations, then plan the upgrade path. Confirm which image tag your team will pin, since upgrades become your responsibility.

Community Edition prerequisites

This page lists the compute and database requirements for the build and host steps and names PostgreSQL as the data store set through DATABASE_URL. Size the build machine separately from the host, and provision a PostgreSQL instance with backups before the first import. Your team will also need SMTP settings for email sign-in, so confirm your mail relay early.

CLI overview

The CLI page explains how to run collections with hopp test from a file or from your own instance and write JUnit XML reports. It matters if your Insomnia workflow already runs tests in a pipeline, because the CLI is still marked alpha. Check the Node.js version it requires and pin it in your CI image before you move test runs over.

LICENSE file in the repository

The MIT license file in the Hoppscotch repository sets the terms for using, modifying and redistributing the Community Edition. Legal and procurement teams should read it before approving the deployment, and should separately check which features sit behind the Enterprise license key. Keep a copy of the version you reviewed with your deployment records.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and a Hoppscotch migration follows the same pattern. The work covers the Hoppscotch instance itself, the PostgreSQL database set through DATABASE_URL, the container deployment, sign-in through the OAuth providers and SMTP settings your administrators choose, and the export and import runs that move collections and environments out of Insomnia. Most engagements are fixed-scope, so the written scope should name which Insomnia projects move, which workspaces and members are recreated, and which sign-in method the team uses before any work begins.

A quote follows from that written scope, so the figures you receive depend on what you ask DeployOpen to do and what your own teams keep doing. Ask the proposal to separate one-time work (planning, installation, the first import, sign-in configuration, handover) from recurring work (upgrades, backups checks, monitoring and support). Also confirm which parts of the Hoppscotch instance, such as the 50 MB importer limit on self-hosted editions or Community Edition upgrade steps, will be tested in your environment rather than assumed. Ask for the acceptance criteria in writing, including how imported collections are checked against the originals.

Ongoing support and upgrades are available as retainers, which suits teams that will run Community Edition for a long period and want someone accountable for quarterly releases, backups and the next upgrade. Decide early who owns the instance after handover, who holds the administrator role, and where backups and secrets are kept, because those decisions shape the retainer scope more than the migration itself. DeployOpen does not issue audit reports, attestations or certifications. If your assessors need evidence of how the platform is configured, we prepare the systems, controls and records for them, and independent auditors and certification bodies make the determination.