Why you should shift from ENV files to Configuration-as-Code

Greetings, fellow developers! Today we’re diving into the world of application configuration. We’ll discuss the drawbacks of using environment variables stored in ENV files and why Configuration-as-Code (CaC) is a much stronger approach.

The Challenge with ENV Files

As developers, we often find ourselves managing a vast array of configurations that vary across environments and are stored in multiple systems. This can be a daunting task, involving error-prone, tedious work that hinders DevOps automation and slows down our development process.

One common approach that leads to this challenge is the use of environment variables stored in env files. While this method is simple and straightforward, it starts to show its drawbacks as our applications grow and become more complex.

According to the Twelve-Factor App methodology, an app’s configuration values should be strictly separated from its code and should vary between deploys. The problem with using env files is that they often become too closely linked to the codebase and can be mistakenly checked into version control or become outdated when kept locally.

Moreover, as Diogo Mónica pointed out in his article “Why you shouldn’t use ENV variables for secret data”, environment variables can be easily exposed, either through error messages, debugging, or subprocesses. This can lead to secret data being leaked, posing a significant security risk.

The Power of Configuration-as-Code (CaC)

So, what’s the solution? Enter Configuration-as-Code (CaC). With CaC, we treat application configurations as code. This means we can use the same practices we use for our codebase—like version control, code reviews, and automated testing—for our configurations.

Here’s how CaC addresses the issues we discussed above:

Consistency and Reproducibility: With CaC, configurations are declared once and then managed using code, ensuring consistency across different environments. No more juggling multiple env files!

{
  "LOG_LEVEL": {
    "type": "RegEx",
    "pattern": "^(debug|info|warn|error)$",
    "default": "info",
    "required": true,
    "description": "Represents the severity of the log events passed to the stdout"
  }
}

Security: By treating configurations as code, we can use the same security practices we use for our codebase. This includes keeping configuration values out of the code repository and using secure methods to store them, especially secret data.

Scalability: CaC allows us to easily adjust and scale configurations as our application grows. We can add, modify, or remove configurations as needed, without having to manually update multiple env files.

Collaboration: With CaC, developers, operations teams, and stakeholders can work together on configurations without bottlenecks. Changes can be proposed, reviewed, and approved just like any other code change.

Configu: Bringing CaC to Life

At Configu, we’re big fans of IaC and through that CaC. That’s why we’ve built an open-source project that makes implementing CaC a breeze. With Configu, you can manage and orchestrate configuration data across different environments and systems, all through a single, flexible, and extensible interface.

Let’s walk through a practical example. Suppose you’re working on an application that uses a database. Instead of storing the database credentials in a .env file, you could define them in a schema file using Configu. This file can then be versioned and reviewed just like any other code file. When it’s time to deploy, Configu can retrieve the parameters and credentials from a secure store and inject them into your application, all without juggling multiple env files and exposing them to the environment.

Conclusion

In conclusion, while env files can be useful for simple applications, they can cause issues as your application grows and becomes more complex. Configuration-as-Code offers a powerful alternative, allowing you to manage your configurations with the same care and precision as your codebase.

So, the next time you’re about to create a new env file, consider giving CaC a try. Your future self (and your fellow developers) will thank you.

Happy coding!