When testing APIs, software engineers often repeat identical values across multiple requests, but who wants to waste time typing the same values every time? 

Insomnia’s environment variables solve this problem by allowing you to define a value once as an environment variable and reference that value wherever it’s needed. Insomnia also enables you to override certain variables using sub-environments or folder environments. Standard variables are base URLs, authentication tokens and resource IDs, but you can create any variables that help you save time.

Eventually, you’ll run into a request that requires some form of authentication. The issue with storing passwords in plain text is that anyone can read them.

The Solutions We Discovered Together

This issue prompted the community to question how to avoid plain-text passwords in the “Manage Environments” section of Insomnia. Thanks to a combination of community contributions and Insomnia features, you can easily avoid this situation through various options:

1. Use Private Environments

The easiest solution is to use private environments. A private environment will never be exported or synced. However, it will still be in plain text, so it doesn’t completely solve the issue at hand, but I wanted to point out that it is available. 

2. Use ENV Files

My preferred option would be using env files. An Insomnia plugin created by community member Edirin made this possible. Huge thanks to him for creating this Insomnia Plugin – dotenv that makes it tenfold easier to use env files in environments. 

To use Edirin’s creation:

1. Open Insomnia preferences. The shortcuts are (Ctrl + ,) or (Cmd + ,) depending on your operating system. 
2. Navigate to the Plugins tab and type in “insomnia-plugin-dotenv” in the search bar. 
3. Click “Install Plugin.”

The alternative, and perhaps easier, installation method is to visit the plugin hub and click the “Install in Core” button on the top right.

After installing the dotenv plugin: 

1. Navigate back to the “Manage Environment” page. 
2. Create a key-value-pair where the value references the “dotenv” plugin you just installed. The process uses regular JSON, so add your key, and when typing the value, press ctrl + space (or cmd + space) and select the dotenv plugin from the autocomplete dropdown. Then, click on the tag and configure the plugin. Here is an example of what it would look like:

3. Choose the .env file and which variable name you need to retrieve from it. The live preview below is a nice touch to ensure you see the value assigned to the variable. 
4. Click “Done,” and you’re good to go!

3. Use ENV Files With Sub Environments

Opender took it one step further by utilizing the Insomnia Plugin – dotenv alongside sub environments. 

1. As seen in this sample environment, you’ll want to map each variable against the env file in the base Insomnia environment. 
2. Specify an envFilePath variable in the three sub environments, e.g., .env.local, .env.staging and .env.production.
3. Most importantly, when consuming the dotenv plugin, reference the envFilePath variable instead of hard-coding it.

This is handy for collaboration. The environment variable setup is shared (in the base environment). Still, each collaborator provides the specific keys from a file on their file-system, which is never synced or exported. 

Thank You, Insomnia Community!

The results of this collaboration to avoid plain-text passwords in Insomnia demonstrate two things:

1. The community is incredible.
2. Insomnia is awesome.

The combination of these two created a fantastic new plugin and excellent use case. I’d like to make one last shout out to Alex for kicking it off in the following GitHub issue. We’re all a little better at protecting our plain-text passwords now, thanks to you.

You can explore the other 250+ Insomnia plugins available on the Plugin Hub. There are tons of excellent open source plugins. If you can’t find something you need, Insomnia has documentation to help you create your own.

Check out our recent blog post for even more Insomnia tips: Service Design Guidelines with OpenAPI and Kong