An environment variable is a dynamic-named value that can affect the way running processes will behave on a device within a particular environment. Developers will initially build a local and development server for testing all the tools and features within the website application before deploying to a production environment. Simple ways to store shared resources, secret authentication tokens or access keys, and CDN or database locations can easily be saved within the .env file and loaded within any supported javascript or web application development framework. As important as it is to save these important bits of information, storing them in these config files for the development server is a big security risk. Below we’ll break down how to configure a local and development .env file then best practices for storing production environment variables.

Development vs. Production Environment

When it comes to editing config files, whoever has the task has complete access to the .env with every secret in the file. It’s obvious why this is a major issue when it comes to production and leaking sensitive information.

The localhost is a hostname that refers to the current device used to access it. It is used to access the network services that are running on the host via the loopback network interface.

Typically, a server in a development environment allows unrestricted access to and control by a user or group of users. A production server, on the other hand, is configured to restrict access to authorized users and to limit control to system administrators. For example, in a development environment anyone might be allowed to shut down the server, whereas, in a production environment, only an administrator with appropriate privileges would be allowed to stop a running server.

DB_ENDPOINT = https://app.website.com/db/v1
DB_USER = admin
DB_PASSWORD = d9v3ndik!3$#0fn8EL2naQF

Leaving the file within the repository is truly only acceptable for localhost development of a website application. Once deploying to a dedicated development server, it would be best to have those settings treated as if it were production to best simulate reality. It makes sense to keep the file within the repository to help with versioning, but this is where we would want a better approach. Chances are once the localhost is setup, the config files can be stored with a shared development setup and all access to the generic information.

When we go to a real server, this calls for a separate config server to store both the development and production .env files. Depending on choice of dedicated config server, you may have added features for versioning. Regardless, information can be stored in a different location for only those that require access to update sensitive information may deploy the data independent of the entire web application.

Config Server

A hosting solution such as Heroku or Netlify allow for publishing applications or websites with sensitive environment variables. Many cloud services can function as a config server like AWS Parameter Store, Google Secrets Manager, or HashiCorp Vault for the open-source enthusiasts. With a config server, all sensitive information is centralized, encrypted, and only be accessible by applications and users you approve.