# Feature request: .env files

**URL:** https://discourse.nodered.org/t/feature-request-env-files/88927
**Category:** Feature Requests
**Created:** [25 June 2024 07:54 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927 "2024-06-25T07:54:15Z")
**Posts on this page:** 13
**Page:** 1

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [25 June 2024 07:54 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/1 "2024-06-25T07:54:15Z")

</div>

As a flow designer using Node-RED, I need a straightforward way to manage project-specific environment variables for my local (development) environment without altering the Node-RED settings.js file or setting them via Global Environment Variables (stored with the flow).

To achieve this, I would like to store these 'local' env variables in an .env file located alongside my flow file. This technique should work on platforms like Windows, Linux and Mac (I'm running on Windows).

This method allows me to seamlessly switch between projects, maintain organized configuration management, and work with variables tailored to my local machine for the active flow. For different instances such as Testing, Acceptance, Production environments or other Dev machines, separate .env files can be used. When utilizing Node-RED's project feature, I ensure to add the .env file to .gitignore to protect sensitive data like API keys and workspace locations specific to each environment from being exposed.

Also noticed the topic below where this was discussed:

> [@\[Proposal\] Global Environment Variable](https://discourse.nodered.org/t/proposal-global-environment-variable/65560/7):
>
> If they need to be typed then I think they may need a different name... when I think of environment variables then they should always just be simple strings. (and I would vote for them to be held in a .env file - but I can see this would cause issues on systems where you may not have a file system)

---

<div class="post-metadata">

### Author: ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)
#### Post date: [25 June 2024 08:08 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/2 "2024-06-25T08:08:08Z")

</div>

I don't know how this works with Projects but if you start Node-red with a systemd service (Linux) then there is a parameter EnvironmentFile in the systemd script which will be pre-set to either `EnvironmentFile=-/home/pi/.node-red/environment` or (if Node-red was first installed a while ago) `EnvironmentFile=-/home/pi/.node-red/EnvironmentFile`

You can define variables in there using standard Linux syntax `MYVAR="Hello World"`

---

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [25 June 2024 10:05 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/3 "2024-06-25T10:05:40Z")

</div>

Thank you for your feedback. I've read about systemd, but unfortunately, I'm using Windows. I'm switching between projects during the day (different customer projects, very different flows) so ideally I would have something like an environment file sitting next to my flow file.

---

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [25 June 2024 11:56 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/4 "2024-06-25T11:56:54Z")

</div>

So I basically look for dotenv support.

> **[dotenv](https://www.npmjs.com/package/dotenv)**
>
> Loads environment variables from .env file. Latest version: 16.4.5, last published: 4 months ago. Start using dotenv in your project by running \`npm i dotenv\`. There are 47187 other projects in the npm registry using dotenv.

---

<div class="post-metadata">

### Author: ![AndrewBeasley](https://avatars.discourse-cdn.com/v4/letter/a/f17d59/32.png) [@AndrewBeasley](https://discourse.nodered.org/u/AndrewBeasley)
#### Post date: [25 June 2024 15:36 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/5 "2024-06-25T15:36:24Z")

</div>

> [@evdheuvelUpl](#):
>
> I'm switching between projects during the day

How about Docker?

Create a basic container and then clone this per client - give each a different port for the GUI / Dashboard if you need to run multiple ones at once...

One advantage is that you can have multiple versions on your box at once if you need it.

Lighter than a VM per client (though I've done that before for sone jobs) but you may need this way if you deploy on Windows rather than Linux.

---

<div class="post-metadata">

### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [25 June 2024 18:44 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/6 "2024-06-25T18:44:28Z")

</div>

You don't need Docker to run multiple instances of Node-RED. It is a Node.js app and so is easily run multiple times with different settings.js files or even with different versions of Node-RED by installing locally rather than globally.

You could also use the dotenv package loaded into settings.js and use them there.

However, the question was specifically about the use of Node-RED projects - personally, I wouldn't use projects to separate test/live instances but hey, each to their own.

---

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [26 June 2024 06:56 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/7 "2024-06-26T06:56:41Z")

</div>

Hi Andrew,

I've been using containers extensively for my work, which enables me to deploy our nodes at various stages (official release, bleeding edge, older releases, etc.). Additionally, I often have containers running on the side for MSSQL, MySQL, and WordPress, all configured through Compose files. I really love this setup as it allows me to run multiple instances concurrently.

Unfortunately, most of our customers are more conservative and haven't adopted containers yet. They prefer running software on their Windows boxes and VMs. For them, using an .env approach would offer more flexibility given their current setup, but I'm optimistic they will transition to Docker eventually.

---

<div class="post-metadata">

### Author: ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)
#### Post date: [26 June 2024 07:20 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/8 "2024-06-26T07:20:15Z")

</div>

If Docker is not an option for your customer production setup, I'd go with the suggestion Julian (@TotallyInformation) made.

Try to load you env files from settings.js with the dotenv package.  
It's easy to integrate, adds the env vars to `process.env` and wouldn't require any changes to the runtime.

---

<div class="post-metadata">

### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [26 June 2024 08:19 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/9 "2024-06-26T08:19:44Z")

</div>

> [@evdheuvelUpl](#):
>
> Unfortunately, most of our customers are more conservative and haven't adopted containers yet.

Containers have their own issues, especially in commercial environments and aren't always a brilliant solution however much they may seem like relatively "easy" answers for IT people. 😀

Sometimes running things native is better, especially if you have DevOps tooling in place.

---

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [26 June 2024 11:58 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/10 "2024-06-26T11:58:22Z")

</div>

Looked at adding dotenv as suggested. Adding the following before module.exports made it work on my Windows setup:

```auto
require('dotenv').config({ path:`${__dirname}/.env`})

```

Think this is already a great start and something we can add to the configurations of our customers. Plan to explore a method to link this to the active Node-RED project (I still think that would be a fantastic improvement 😉 )

Thanks all, appreciate your feedback and pointers!

---

<div class="post-metadata">

### Author: ![joepavitt](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/joepavitt/32/59722_2.png) [@joepavitt](https://discourse.nodered.org/u/joepavitt)
#### Post date: [1 July 2024 08:40 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/11 "2024-07-01T08:40:00Z")

</div>

> [@evdheuvelUpl](#):
>
> This method allows me to seamlessly switch between projects, maintain organized configuration management, and work with variables tailored to my local machine for the active flow. For different instances such as Testing, Acceptance, Production environments or other Dev machines, separate .env files can be used.

Have you considered [FlowFuse](https://flowfuse.com)? It provides full project/instance management, "pipelines" to easily push between different staging environments, and management of environment variables on an instance-by-instance basis

---

<div class="post-metadata">

### Author: ![evdheuvelUpl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/evdheuvelupl/32/68644_2.png) [@evdheuvelUpl](https://discourse.nodered.org/u/evdheuvelUpl)
#### Post date: [1 July 2024 09:12 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/12 "2024-07-01T09:12:00Z")

</div>

Hi Joe,

Yes, considered it and love the concept. Especially, as we use pipelines ourselves to push flows and other resources from our git server to clouded NR environments. This technique provides a very elegant setup. Admittedly we had set this up before we learned about FlowFuse.

Many of our clients integrate with other on-premises software and equipment such as printers and inserter machines, which complicates operation in hybrid environments due to networking challenges. Our core product is document composition software primarily designed for on-premises use (today). This software specializes in creating highly personalized documents and automating business communication, including promotional letters, policy documents, invoices, and statements. It features its own REST API that we integrate with Node-RED and other applications. Specifically for Node-RED, we have developed a set of nodes that seamlessly connect with our software, enhancing the efficiency of typical document composition processes. (Check out @objectif-lune and @objectif-lune/node-red-contrib-connect on npm for more details.)

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)
#### Post date: [30 August 2024 09:12 UTC](https://discourse.nodered.org/t/feature-request-env-files/88927/13 "2024-08-30T09:12:25Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
