Local-only projects are back in Insomnia 8.3 (GA). · Kong insomnia · Discussion #6626

Believe it or not, when we released Insomnia 8.0 we wanted to actually do good

For who? For Kong?

Do I still need an account?

You will need an account with Local Vault

You haven't learned your lesson, have you?

My biggest lesson is that E2EE is not that useful to many users, after all

Really? Do you think E2EE is the reason for push back? Not the mandatory login? Are you even listening?

You turned Insomnia from useful product into a freemium cashcow with a demo version (Scratchpad).

What's the moat, besides having a large non-monitised user-base?

Other free alternatives now exist and people will just switch. Why would they go back? How should your paying customers trust you won't do a stunt like that again in a year from now?

That's great news! Thanks for listening to the community! Actually having these two options and possibility to move between them may be even better than having only one for all parties involved

• Please, do not force users to be registered on your external services. Not everyone can/want to do it. You closing door to work with tool as with really standalone app
• Return back all functions was before for free users (workspaces, sync, tests, whatelse I missed?)
• Insomnia developed with active support of users, with your community. Yes, it is your product, but built with love and time of big community of developers. Please be in contact with your community, before you will decide to turn out from them again

We understand you doing the business, please understand your users as well.

You will need an account with Local Vault

This still gets to the heart of the problem and why there is push back. If I sign into the application, there always runs the risk that my data will be pushed to the cloud. I know, I know; Kong will promise this will never happen without my consent. But I cannot operate on a trust model when I am working with my org's sensitive data where uploading their data is not allowed and the consequences of doing so is severe.

You guys got it so, so close.

I went through the same wild ride as many other people here: unwittingly upgrade to 8.0, panic as all of my data disappeared with a ransom to create an account, downgrade to 2023.5, exhale a sigh of relief as my data returned, and finally accept that Insomnia has reached the end of its useful life.

While seeking alternatives, I was relieved to see that Kong had a change of heart and would continue to support local-only storage. What's a couple more weeks on an old version that's served me well in exchange for a neat update with complete feature parity with the previous major version?

And then came this...

You will need an account with Local Vault

At this point I'm reminded once again, if it's too good to be true, it probably is.

You (as in, Kong) tried so hard to express humility and understanding for your local-only users, only to miss the mark once again. It makes no sense to have to register for an online account to use a local tool. There's no justification for it aside from corporate greed to convert users and mine data.

I'm not one of those "never again" types; people and companies change all the time, and in most cases, trust can be re-earned. But your post today in response to major backlash demonstrates a commitment to short-term monetization at the expense of trust from users. You already had an uphill battle ahead of you, and now the slope is even steeper. I wish your company the best of luck, but for now, my organization and I will be trying something else.

I reverted to the old version of the app, disabled automatic updates, then this morning it was back to 8.0 again. Make it make sense.

I remember being hesitant to use this at first because my team had been using Postman, but the UX felt overwrought to me.. sucks that I'm being forced to switch back.

I don't mind paying for stuff, but this approach is awful.

Yes, this isn’t as bad as everyone is making it out to be. It isn’t an unfair ask of users to create an account. Was it poorly communicated? Yea, but is it an unfair ask? No, it really isn’t. Insomnia wants to continue innovating a great product. I just can’t believe the entitlement the users of OSS feel. You don’t deserve the work of others for free, forever.

Insomnia wants to grow, and need the ability to promote paid services. They’re not even asking you for money. If insomnia had a paid subscription for local only functionality, would you pay it? More likely than not, you wouldn’t. You’d rollback to the previous release, and not support the effort and creativity of the authors. Even though your whole company benefits from its functionality.

To those saying, “but they could upload my data if I make an account”! Really, if you’re not already using LittleSnitch to block/monitor outbound network requests, than are you really concerned about security?

Anyways, I’m likely to get downvoted for this, but I’m willing to support those whose work I benefit from.

Now after update how can I restore my old requests? Going to scratchpad and it's all empty - is it all lost now?

Believe it or not, when we released Insomnia 8.0 we wanted to actually do good.

I'm confused what "good" you did for the average user, who just wants to send HTTP requests. There's a lot of new features for organisations & teams, and I don't doubt that there's been a lot of effort put into that, but other than that, the only new major features for people who use Insomnia offline (which is clearly a lot given by the backlash to the update) is the "highly-requested" scratch-pad, which, is just a worse version of what we were already using with an annoying banner advert, and SSE API support, which was already supported in Insomnia months ago.

I understand that you're running a business, and that you can't keep maintaining a product out of goodwill forever, but there are better ways to go about it than users opening the app, expecting the usual, but instead being dropped to a mandatory sign in page without any warning. If you say, added useful features that was only available on the paid plans, while keeping the experience as is for free users, I'd consider signing up, but this is how you kill any user trust or good will.

We need to hire more people to do that, so I hope you understand why we are requiring an account (can be free) in order to use the product.

No, I don't understand, why are you requiring a free account for a local app usage?

Or, actually, I do understand, but I want it to be said clearly instead of using sly hints

I'm sorry, but I will stop using insomnia soon. For now I continue working with old version while not found solution better, but it is very low chance that I will come back to insomnia again ):

I had a few plugins, some small fixes I still can do, but without testing on latest version of insomnia I won't be able to support them.

I was waiting for Kong team step toward community, but it seems you have a plan where you don't want to hear users. This is sad... if someone from Kong team somehow will read this message, and you will have a question "what you don't want to hear from users", please read my first message I send right after you created this discussion or any other from here

It will be like reddit drama when they made API changes. they just waited until the rage is over and continued like nothing happended.
I think same will happen here, so best thing is to switch to other alternatives instead of waiting for them to do something.

The two fundamental problems here are that corporate security says you can't login to something that doesn't have a proper security relationship with the company if you're storing customer data, etc in it - whether it be local or not.
And second: AIR GAP. How do you use Insomnia without internet access? How do you use Insomnia if you're standing in a data centre with your laptop directly connected to the switch trying to fix something. My entire ecosystem is tiered - the internet facing webservers are contactable from the internet via F5 security appliances / load balancers but have ZERO outgoing internet connectivity. And the API servers are a tier behind that in subnets that just have never had even a sniff of internet.

We just want a tool we can run locally. Simple.

Insomnia 8.3 update (fully local storage is back)

With Insomnia 8.3 (available today) we have brought back 100% local storage with no cloud synchronization for your projects, while at the same time keeping the same workflow for users that want to collaborate in the cloud. This means that now Insomnia supports:

1. Cloud Sync: e2ee cloud synchronization for collaboration.
2. Local Vault: local storage for all files in a project.
3. Git Sync: using a 3rd party Git repository for storage (this doesn't require cloud access and never did).

By supporting all three options, I believe this makes Insomnia the most comprehensive solution for API development and debugging and can cater to pretty much every use-case.

Migrating from pre-8.x to 8.3+ will also now default to migrating to Local Vault, while still showing the optional Cloud Sync for users that want to collaborate together. This is to avoid the situation where someone mistakenly transfers projects to the cloud if they are not allowed to do so by their employer.

Account management is still done in the cloud on insomnia.rest: no local projects are stored in the cloud even when creating an account, which is used for managing collaborators for any cloud projects that you may have now or in the future, for managing organizations and their users, and for managing billing and upgrades and so on. More cloud features will be shipped in the future, that will be managed via the cloud website as well.

Scratch Pad is still there, and is local by default and does not require an account.

Here is a video that shows how to convert a Cloud Sync project to Local Vault, and vice-versa: https://www.loom.com/share/ca2e859698d54e58a871c33da570213f

Local Vault and Cloud Sync

You can now create local projects in addition to cloud projects, and even have a mix of both. If you have a cloud project today and want to convert it to local project, you can click on the "Project Settings" and make that change.

When a project is created locally, or converted to be local-only, all data in the cloud is permanently deleted. Alternatively, when a local projects grows to a point where cloud collaboration is needed, it can also be converted to Cloud Sync with the same process. Moving back and forth is super easy.

Both projects types (Cloud and Local) can be enabled to support Git Sync if you wish to do so, which always uses 3rd party repository for storing data and never goes to the cloud.

What happens when a project is local?

When creating a Local project, or converting a Cloud project to become Local, we apply the following behavior:

• Local projects have their data permanently deleted from the cloud, even if they had Cloud Sync enabled previously. Of course projects that are local since day one, never use the cloud to begin with.
• Local projects that become Cloud projects, are end-to-end encrypted (E2EE) and stored in the cloud to enable collaboration.
• It is not possible to collaborate on Local projects, because we wouldn't have a way to do that anymore, unless Git Sync is enabled.
• Only organization "Owners" and "Admins" can perform project conversions from/to the cloud.
• When a Cloud project becomes Local, collaborators working on that project will also see a Local project moving forward (it becomes local for everybody). The opposite happens when a Local project becomes a Cloud project, and now collaborators can access it remotely.
• When using Git Sync, the data is always stored in the 3rd party Git repository of your choice and never goes to the cloud. This has always been the case with Insomnia 8.x.

What's coming next?

This whole experience has been a huge learning opportunity for me, and also highlighted some misunderstandings on my part that led to the 8.x changes.

Bias

Before shipping the 8.0 capabilities and removing the local option (except when using the Scratch Pad), we asked for feedback to our users and it never came across as a deal breaker, now it's easy to understand why: the users we reached out to were the ones that already opted into cloud projects (by definition, as they were the only ones that created an account), therefore there was large bias is not considering cloud projects to be problematic and focusing on end-to-end encryption (E2EE) instead.

But there was a significant part of the user-base that was not represented in our explorations, because we had no opportunity to engage with them in any meaningful way as we focused on the ones we could speak to face-to-face and that therefore had an account with Insomnia. Many of you and in this forum were part of this unrepresented user base, and that is the users that legitimately cannot use cloud storage for their projects whether they like it or not, and whether it's encrypted or not.

This was a huge miss on my part and I apologize for the insomnia I have caused.

I now understand the importance of having a local-only storage option for projects that for one reason or another cannot be moved to the cloud, and I am fully leaning into local storage as one of the 3 storage backends we will support in the future. I see it as being a big competitive advantage, as a matter of fact.

Communication

Because cloud projects were never seen as being a problem in those biased conversations, this created a cascading behavior that also resulted in poor communication on my part. Because it never emerged as being a problem (mistakenly, as explained earlier), the need for heavy communication went over my head as we focused on building the product capabilities. One thing led to another, and here we are.

Hopefully with this release we were able to quickly revert our initial thinking three weeks after making our mistake, and also provide a way for users to delete data permanently from the cloud if they need to meet certain compliance profiles and get out of trouble. But doing so in a way that still allows Insomnia to cater to those users that want more and more cloud collaboration features, therefore striking a good balance across the Insomnia user base. With Insomnia 8.3+ you can freely choose between all storage options, based on your requirements.

So, what's next?

Insomnia is a profoundly vast product that covers many areas of the API lifecycle, we support API creation, debugging, testing, an ecosystem of plugins, then we also support a CLI, collaboration capabilities, and a lot more! It is a product that requires a huge amount of investments to keep growing and to keep delivering awesome features to the community and the paying customers.

My job is to make sure that as we keep working on Insomnia we set the product on a path to success. The engineering and support teams will double again within the next 12 months and we will invest more into:

• Supporting all the community features like pre-post request scripting, collections runs, multiple-tabs and more.
• Improving a whole lot the user experience and fixing all the bugs that have been reported.
• Establish a strong community and technical support function that can unblock users in their day-to-day obstacles.
• Doing so by being the best and most cost-effective product at scale for both individual users and large organizations.

The last three weeks were very intense for both you and us. With Insomnia 8.3 and above I want to set a new course for the project that is sustainable and exciting, and move on from the hiccup of the past three weeks to focus on building innovation and features that you can use in the cloud, locally and with Git.

As a matter of fact we will fully leaning into local storage as part of our roadmap, huge unserved use-case and an opportunity for the project:

• We will build more capabilities around controlling where data is stored, and allow the owner of an organization to also remotely de-provision local data for users that should not have access to it anymore. And with that, all local API credentials too.
• We will add management capabilities to mandate projects to only be Local (or Cloud, or Git) for all collaborators or employees of an organization, that can be setup from the cloud organization admin panel. And more.
• We will also fully pursue SOC2 compliance (and more) for Insomnia, so that you have the peace of mind that when data is stored in the cloud, it is also secure and end-to-end encrypted and you can freely collaborate on your API projects without complex import/export flows that don't scale.

This will be the new Insomnia homepage this week as we fully lean into local-only as one of the options.

There will be more 8.x releases coming soon as we keep improving the product, you will always have access to your local projects across every future update.

Cheers,
Marco

E2EE has nothing to do with the pushback. It's the fact that Insomnia wants to manage everything for you despite missing a lot of features.

For example, on my end, I would need full OpenAPI 3.1 support before I could let Insomnia manage my projects. Otherwise, my flow is to have files locally (but local is a misnomer, after all I still use Git just with a repo that I manage separately) - so that I can edit my OpenAPI files with an editor that supports references and then commit them to Git but still have Insomnia be able to work with that (after merging those references into a single file that insomnia can comprehend).

We need to hire more people to do that, so I hope you understand why we are requiring an account (can be free) in order to use the product.

No, I don't, and neither do I see how requiring logins equals more income for you. You talk lengths about marketing premium features in that section, but you can shove advertisements in my face without requiring an account, which if I remember correctly is what you already did. In this whole post you don't give a single straightforward reason why accounts are required for local use from now.

Unless you also plan on removing the free account plan, which you of course wouldn't mention because you realize it'd only net you a bigger backlash, I really don't see why requiring users to create an account is necessary or how it makes your business model more feasible.

It'd be great if you communicated your reasoning behind this change with users, but it seems you're categorically ignoring every question regarding this.

If you need revenue can I just pay you instead of having to make yet another account I don't want for a, in your words, "100% local" application?