Best practices to have different variables for development and production

As you've probably already done. Write your code to use environment variables. (whether you run locally or on production, that's the same code.).

const ACCESS_KEY = process.env.ACCESS_KEY;

Your .env file then contains ONLY your local settings, for debug on your local computer. You can add .env in your .gitignore file to make sure it doesn't get pushed to your git repository.

Production settings by contrast shouldn't be in any file at all. They should only be configured directly in the settings of your cloud provider.

• if you're using Azure, they should be in an Azure Key Vault
• if you're using AWS, they should be in the AWS Parameter Store
• if you're using Heroku, then they should be configured in Heroku's settings.

Heroku settings

It's possible to do this from the "Settings" tab in your heroku app dashboard. There is a section "Config vars".

When heroku launches your application, it will define the configured config variables as environment variables. And you will be able to access them with process.env just as you would with the environment variables which were defined in your .env file during development.

CLI

The dashboard makes it easy to get an overview and to manage the keys. Perhaps even more conveniently, you can also do this with the heroku cli tool straight from the commandline.

To get a list of your current environment variables, run.

heroku config

To add a new key from the CLI.

heroku config:set ACCESS_KEY=adfsqfddqsdf

All of this is also described in the official documentation of Heroku.

Generally, you would generate your env file at build time. For example, using AWS SSM / or some kind of Vault that is secure, you store your secrets like db passwords. The env file is a template that gets compiled with the right env vars for the target deployment.

Also, you can have dummy variables in your env template that you commit to git. Then add a .gitignore file with an entry to your env template to ensure you don't commit any secrets to the env file. Then locally you compile your file for local, during your staging build for staging, during prod build for prod, etc.

As the app gets larger, this allows you to provision credentials per person / per environment. You add the associated secrets / permissions to the vault. Allow the people/environments access to those secrets, and then you can control access in a pretty fine grained fashion.

I suggest using an npm package for handling different environments variables and keys. (or implement it by yourself)

Alongside with .env file

1- use .env file to store credentials and secrets 2- Reference these .env variables via different package that provides separate file for each environment

suggested package : https://www.npmjs.com/package/config

I used this approach in one of my projects and made my life easier.

A widely adopted best practice is to inject at runtime the application settings (secrets and environment config).

It is safer (secrets are NOT stored in the source code, bundles or packages/images) and portable (as you deploy to more environments you only need to define suitable values - no code changes, recompilation or repackaging).

Single .env file

Define a single .env file: your application needs the same properties (with different values obviously) anywhere.

On your local development environment config the .env file for development: you don't commit either package this file.

Production Deployment

Define the runtime configuration: on Heroku use Config Vars to create an environment variable for each property defined in the .env file, for example

   # .env 
   API_TOKEN = dev1

Create a Config Var API_TOKEN with the production value: this is injected at application-startup and never stored/exposed.

This approach is language-agnostic (in Java you might have a .properties instead but the principle is the same) and works with different hosting providers: you would deploy the same app/package while configuring the environment settings accordingly.