Introduction

I have previously blogged about centralized configuration and secret management with Azure App Configuration. This blog post looks at a tool called direnv and .envrc files to augment that configuration and secret management setup to automatically load configuration settings in a local developer scenario.

Direnv

Direnv is a powerful environment switcher for Unix shells that seamlessly integrates with your command line. When you navigate into a directory containing a .envrc file, direnv automatically loads the environment variables defined in that file. Similarly, when you leave the directory, it unloads these variables, ensuring your shell environment stays clean and project-specific.

One of direnv's key features is its security model - it requires explicit authorization before loading any new .envrc file, or if there are changes in the file.

The idea here is to store the local developer setup settings as environment variables in the .envrc file.

Setup

I am using the oh-my-zsh zsh configuration framework, which has native support for direnv. Enabling it is as simple as enabling adding it to the plugins in the .zshrc file, e.g.,

plugins=(git direnv)

I, as quickly as possible, usually add an entry to my .gitignore

**/.envrc

Distribution

In my current project, we distribute these .envrc files by storing them as a base64-encoded string secret in Azure KeyVault. One of the downsides of this setup is exactly this step: Adding a new entry to the .envrc file requires a new upload, and the other developers must ensure they get the new version by downloading it and decrypting it using a base64 tool. An upside is that a local developer setup regarding the external dependencies requires a fixed set of steps that the developers can generalize for all applications.

Alternatives

There are some alternatives that I considered.

Dedicated Azure App Configurations for local development

There is always the option of only using an Azure App Configuration for local development, which would solve the issue of distributing changes with the direnv approach. However, I decided it would be unnecessarily costly and defeat the notion that I use Azure App Configuration mainly for common configuration.

Azure App Configuration filters

Azure App Configuration provides a labeling system for filtering configurations based on specific labels. By applying labels to configuration values, applications can selectively load only the configurations they need, making it easier to maintain environment-specific settings without creating separate configuration stores. A solution could be to use a dedicated filter for the local development setup.

I wanted to make the separations as clear as possible and ensure that no one bad configuration or Azure App Configuration store deletion takes down all apps in all environments. Additionally, with the filtering system, I have not seen any way to ensure that misconfigured applications do not get access to initially denied configurations.

Dedicated app settings files

Creating local configuration files (e.g., appsettings.Development.json for .NET applications) is common. However, they can not contain secrets. It is an option to store these local configurations with secrets using base64 encoding, but now we are looking at a "poor man's version" of the direnv tool.

Summary

This post discusses local application configuration management, focusing on using direnv and .envrc files to complement centralized configuration solutions like Azure App Configuration. The key points covered are:

• The use of direnv for automatic environment variable management in Unix shells
• Distribution of .envrc files through Azure KeyVault as base64 encoded strings
• Security considerations and the requirement for explicit authorization of .envrc files

Alternative approaches are:

• Dedicated Azure App Configuration instances for local development
• Using Azure App Configuration's filtering system
• Local appsettings files

The chosen approach with direnv, while having some distribution challenges, provides a clean and project-specific way to manage local non-common development environment variables.