Ability to toggle multiple environments

[dmlittle]

It'd be nice to have the ability to have multiple environments enabled in a certain workspace at any given time. This would allow you to have an environment and a private environment active at the same time to protect information that you might not want to accidentally expose.

For example, if you're dealing with an API you might have different Insomnia environments for different product environments (for example: local and production). This way I can have a production environment and a private production environment enabled at the same time. Optionally, you could also have protected environment keys that will not get exported when you export a certain environment.

Production Environment

{
  "host": "https://api.service.com"
}

Private Production Environment

{
  "API_KEY": "<SOME_SECRET_KEY>"
}

Local Environment

{
  "host": "http://127.0.0.1:8443"
}

Private Production Environment

{
  "API_KEY": "<SOME_OTHER_SECRET_KEY>"
}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bboure]

+1
I have the need to have something similar but I was thinking more in nested environments rather than enabling more than one at the same time.
Example:

• I have dev and production sub environments.
• I want to test the API for different users.
• I create sub-sub-environments for each user under the already existing development/production and put (overwrite) there the api_key variable related to each user.
  Then I can easily switch user under a same env.

The issue I see with multiple selected environments is to know what to do when you have conflicts (variables present in several selected environments). How do you resolve them?
Nested environments solves this issue by using variables by bubbling up from the selected env to the top.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[StanSvec]

Is this feature still planned to implement? I'd like to migrate from Postman in my current company, but difficult to do it without this functionality.

[iakko]

I really need this too, is there a plan for this feature?

[aytacworld]

I need this feature too, but I found a workaround for this problem
Insert all your variables inside Base Environment but add them by group then by environment. eg

{
  "API_Server": {
    "testing": {
      "api_server_url": "https://testing.website.com/api"
    },
    "staging": {
      "api_server_url": "https://staging.website.com/api"
    }
  },
  "User": {
    "admin": {
      "username": "Admin"
    },
    "moderator": {
      "username": "Mod"
    }
  }
}

Then create one Sub-Environment with variables to select per group which environment and the variables itself

{
  "API_Server_environment": "testing",
  "User_environment": "moderator",


  "API_Server": {
    "api_server_url": "{{ API_Server[API_Server_environment].api_server_url }}"
  },
  "User": {
    "username": "{{ User[User_environment].username }}"
  }
}

So you only have to change "*_environment" variables to use the environments you want.

  "API_Server_environment": "testing",
  "User_environment": "moderator",

[stebberg]

Hey, this is actually interesting... not how you want it of course, but one way to ... kind of solve it.
Thank you so much! Had no idea u could have settings in levels and point to them like that 🙈

[jostFT]

any updates on this?

[acomagu]

I think "extending other env" feature also works as solution of this problem(not implemented; the feature I want).

For example:

Production Environment:

{
  "host": "https://api.service.com"
}

Private Production Environment:

{
  ...{{ prod }} // Means extending the Production Environment
  "API_KEY": "<SOME_SECRET_KEY>"
}

Local Environment

{
  "host": "http://127.0.0.1:8443"
}

Private Local Environment

{
  ...{{ local }} // Means extending the Local Environment
  "API_KEY": "<SOME_OTHER_SECRET_KEY>"
}

[swiknaba]

I absolutely do not want to copy-paste all my requests for each environment and keep them all in sync.

But I also absolutely cannot put credentials in the environment (since it is git-synced).

In the current state, sadly, Insomnia is really not usable across a team in production use.

Postman solved this by assigning a "current" and a "initial" value to each environment variable, and NOT exporting/syncing the "current" value, but only the "initial" value. Sadly, Postman is unusable as well, because it forces you to sync and you can't really use it locally without internet (amongst tons of other issues).

[Rowan-Gudmundsson]

Any update on this issue?

[enricojonas]

We are also interested in this one. We need to combine environments, let's say some parameters based on which environment to use (stage/prod) and some parameters based on another criteria, e.g. country.

[Ordiel]

This seems to be a feature that at least some folks seem to need, is there any update on this, or at the very least can some of the maintainers give some pointers in where and what to look to get this done? That way maybe someone of those interested can pick that up. Who knows it could be me 😅

[iakko]

6+ years since this feature has been requested and not even a feedback. Not good.

[stebberg]

I just CAN'T understand why nested environments are not in every rest client!! :-)
Insomnia is by far the best with their base-level thing, but it wont help me though. For me it would be enough with 2 levels per environment, but of course the perfect solution would be to build environments in a tree with unlimited public and private nodes.

I must be using rest clients wrong or something..
If I have a stage environment with an API gateway (=2 different urls to my service) how do I solve this? I need to have 2 environments setup (Stage1 + Stage2) and maintain them with the exact same context and payload. The only thing differs is the url.

[qualitybydesign]

I also need another level of nested environments. I triage issues for multiple internal and external customers that I have to switch between so I want something like this:

• base env: vars that apply in all envs
  • base-prod - vars that apply to all prod envs like host, api-key
    • prod-xyz: customerId, customerDivision, for customer-xyz
    • prod-e2e: customerId, customerDivision for end-to-end test account
  • base-stage: vars that apply in all stage envs, like host, api-key
    • stage-1: customerId, customerDivision for some team
    • stage-2: customerId, customerDivision for another team

[gatzjames]

Hi everyone,
We recently introduced global environments which should cater to most advanced use cases for environment variables in the app. https://docs.insomnia.rest/insomnia/global-environments

Please try it out and let us know if it fits your workflows and how we can improve them!