Feature request: .env files

[evdheuvelUpl]

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

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)

[jbudd]

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"

[evdheuvelUpl]

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.

[evdheuvelUpl]

So I basically look for dotenv support.

dotenv

[AndrewBeasley]

@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.

[TotallyInformation]

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.

[evdheuvelUpl]

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.

[kuema]

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.

[TotallyInformation]

@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.

[evdheuvelUpl]

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

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!

[joepavitt]

@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? 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

[evdheuvelUpl]

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.)