config vs dotenv vs dotenv-expand vs dotenv-flow
Environment Configuration Management
configdotenvdotenv-expanddotenv-flowSimilar Packages:

Environment Configuration Management

Environment configuration management is crucial in web development for managing application settings and secrets across different environments (development, testing, production). These packages facilitate the loading of environment variables from configuration files, ensuring that sensitive information is not hardcoded into the application. They provide a structured way to manage configurations, enhancing security and flexibility, and allowing developers to easily switch between different configurations without modifying the codebase.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
config06,425207 kB1323 days agoMIT
dotenv020,33493.3 kB62a month agoBSD-2-Clause
dotenv-expand01,04919.5 kB37 months agoBSD-2-Clause
dotenv-flow090060.3 kB82 years agoMIT

Feature Comparison: config vs dotenv vs dotenv-expand vs dotenv-flow

Configuration Management

  • config:

    The config package allows for a hierarchical configuration management system, supporting multiple configuration files for different environments. It enables overriding configurations based on the environment, making it ideal for complex applications with various settings.

  • dotenv:

    The dotenv package loads environment variables from a .env file into process.env, providing a simple way to manage configuration without the need for complex setups. It is best suited for projects that require basic environment variable management.

  • dotenv-expand:

    dotenv-expand extends dotenv by allowing variable expansion, enabling you to reference other variables within your .env file. This feature is particularly useful for managing complex configurations where values depend on other variables.

  • dotenv-flow:

    dotenv-flow enhances dotenv by supporting multiple .env files for different environments, allowing for automatic loading based on the NODE_ENV variable. This is beneficial for projects that need to maintain separate configurations for development, testing, and production.

Ease of Use

  • config:

    The config package has a steeper learning curve due to its hierarchical structure and support for multiple configuration files. However, it offers powerful features for managing complex configurations once mastered.

  • dotenv:

    dotenv is very easy to use, requiring minimal setup. Simply create a .env file and the package will automatically load the variables into process.env, making it ideal for beginners or small projects.

  • dotenv-expand:

    dotenv-expand builds on the simplicity of dotenv, adding variable expansion without complicating the setup. It remains user-friendly while providing additional functionality for managing environment variables.

  • dotenv-flow:

    dotenv-flow is also user-friendly, allowing for seamless management of multiple .env files. It requires a bit more setup than dotenv but simplifies handling different environments.

Extensibility

  • config:

    The config package is highly extensible, allowing developers to create custom configuration loaders and integrate with external sources, making it suitable for large-scale applications with complex requirements.

  • dotenv:

    dotenv is not designed for extensibility; it focuses on simplicity and ease of use, making it less suitable for complex configurations that require additional features.

  • dotenv-expand:

    dotenv-expand adds extensibility to dotenv by allowing variable references, but it does not provide a framework for more complex configurations or integrations.

  • dotenv-flow:

    dotenv-flow offers some extensibility by supporting multiple .env files, but it is primarily focused on managing environment variables rather than providing a customizable configuration framework.

Support for Multiple Environments

  • config:

    The config package excels in managing configurations for multiple environments, allowing for easy overrides and a structured approach to environment-specific settings.

  • dotenv:

    dotenv is primarily designed for single-file loading of environment variables and does not inherently support multiple environments without additional setup.

  • dotenv-expand:

    dotenv-expand does not provide support for multiple environments on its own; it focuses on variable expansion within a single .env file.

  • dotenv-flow:

    dotenv-flow is specifically designed to handle multiple environments, automatically loading the appropriate .env file based on the NODE_ENV variable, making it ideal for projects with distinct configurations.

Community and Maintenance

  • config:

    The config package has a solid community and is actively maintained, ensuring ongoing support and updates for best practices in configuration management.

  • dotenv:

    dotenv has a large user base and is widely adopted, with regular updates and a strong community backing, making it a reliable choice for environment variable management.

  • dotenv-expand:

    dotenv-expand is a smaller package with a more niche use case, but it is maintained and works well in conjunction with dotenv.

  • dotenv-flow:

    dotenv-flow is also actively maintained, with a focus on enhancing dotenv's capabilities for managing multiple environments, supported by a growing community.

How to Choose: config vs dotenv vs dotenv-expand vs dotenv-flow

  • config:

    Choose config if you need a comprehensive solution that supports multiple configuration files and environments, allowing for hierarchical configuration management and easy overrides.

  • dotenv:

    Choose dotenv for a simple and straightforward way to load environment variables from a .env file into process.env, ideal for smaller projects or when you need a quick setup.

  • dotenv-expand:

    Choose dotenv-expand if you need to handle variable expansion in your .env files, allowing you to reference other environment variables within the same file, which is useful for complex configurations.

  • dotenv-flow:

    Choose dotenv-flow if you require support for multiple .env files for different environments (e.g., .env.development, .env.production) and want to load them automatically based on the NODE_ENV variable.

README for config

Configure your Node.js Applications

npm package Downloads Issues

Release Notes

Introduction

Node-config organizes hierarchical configurations for your app deployments.

It lets you define a set of default parameters, and extend them for different deployment environments (development, qa, staging, production, etc.).

Configurations are stored in configuration files within your application, and can be overridden and extended by environment variables, command line parameters, or external sources.

This gives your application a consistent configuration interface shared among a growing list of npm modules also using node-config.

Project Guidelines

  • Simple - Get started fast
  • Powerful - For multi-node enterprise deployment
  • Flexible - Supporting multiple config file formats
  • Lightweight - Small file and memory footprint
  • Predictable - Well tested foundation for module and app developers

Quick Start

The following examples are in JSON format, but configurations can be in other file formats.

Install in your app directory, and edit the default config file.

$ npm install config
$ mkdir config
$ vi config/default.json
{
  // Customer module configs
  "Customer": {
    "dbConfig": {
      "host": "localhost",
      "port": 5984,
      "dbName": "customers"
    },
    "credit": {
      "initialLimit": 100,
      // Set low for development
      "initialDays": 1
    }
  }
}

Edit config overrides for production deployment:

 $ vi config/production.json
{
  "Customer": {
    "dbConfig": {
      "host": "prod-db-server"
    },
    "credit": {
      "initialDays": 30
    }
  }
}

Use configs in your code:

const config = require('config');
//...
const dbConfig = config.get('Customer.dbConfig');
db.connect(dbConfig, ...);

if (config.has('optionalFeature.detail')) {
  const detail = config.get('optionalFeature.detail');
  //...
}

config.get() will throw an exception for undefined keys to help catch typos and missing values. Use config.has() to test if a configuration value is defined.

Start your app server:

$ export NODE_ENV=production
$ node my-app.js

Running in this configuration, the port and dbName elements of dbConfig will come from the default.json file, and the host element will come from the production.json override file.

TypeScript

Type declarations are published under types/ and resolved via typesVersions. Subpath typings are included for config/async, config/defer, config/parser, config/raw, and config/lib/util in addition to the main config entrypoint.

Articles

Further Information

If you still don't see what you are looking for, here are some more resources to check:

Contributors

lorenwestjdmarshallmarkstosi­Moseselliotttfmdkitzman
jfelegeleachi­M2kjosxenyoleosuncinarthanzel
leonardovillelajeremy-daley-krsimon-scherzingerBadger­Badger­Badger­Badgernsaboviccunneen
Osterjourth507tiny-rac00neheikesfgheorgheroncli
superovenairdrummingfoolwmertensXadilla­Xinsidedsbert

License

May be freely distributed under the MIT license.

Copyright (c) 2010-2026 Loren West and other contributors