This story explores the big mistake, discusses 9 options for setting the application execution context and helps you choose between them.

The Back Story

Lokesh, one of our backend developers, had a need to toggle a feature in production. And he thought of using an environment variable to do the job. When he was asked “WHY”, he went deeper into it and delivered an amazing session on the use of environment variables and the various other alternatives that we end up ignoring or being unaware of.

Btw, he changed his decision of using an environment variable for the job and made the choice of commenting code and re-deploying. Here’s the story of what he discovered and what made him make this choice.

What are environment variables?

Environment variables set or affect the execution context of our applications. In larger system context, they are referred to as the environment variables that are set at the OS, virtual machine or container level. All applications running within the OS, vm or container will have access to these variables, not just our applications. eg: export PATH="/usr/bin"

The big mistake

We as application developers mistakenly use the word 'Environment variables' for what are actually 'Application config variables'.

This belief is amplified by IaaS services like Heroku that require us to use environment variables. It’s important to understand their context before using this work incorrectly.

Heroku has 2 very good reasons to do this:
1. Every dyno is an absolutely sandboxed environment running only 1 application
2. It does not give you access to write a file to the dyno’s file system, for very good reasons

This leaves them with only one choice, which is a very good choice - to use environment variables.

But we shouldn’t be using them and, even if we do, we should think of them as application config variables, rather than environment variables.

So, what are application config variables?

Application config sets the execution context of our applications based on the deployment environment. It is likely to vary quite a bit based on deployment environments (eg: dev, test, prod, staging).

"Config changes, but code doesn’t. Code can be made open source, config cannot."

Environment Variable Usecases

Multiple options, different use cases

Environment Variable Usecases

Config that’s really code

Environment Variable Configs


Stop using the same hammer for every use case. A good developer knows the various types, and knows which one is the best for the job at hand.