Unable to get set configurations via sourced shell


We have recently decided to go ahead with using n8n as our choice of tooling. It looks promising.
I’m trying a server setup.
I could get n8n running behind nginx, and with pm2. (meaning the web app is correctly visible on the public IP and the nodes are also visible).
Here’s my setup -

I have a production.sh

# SETUP - getting current work dir and public ip address
# other settings are picked up from the json file
MYIP=$(dig +short myip.opendns.com @resolver1.opendns.com)
# load config from this file
# The front end uses this url as it's backend
# Set encryption key to maintain credentials across runs, n8n will generate 
# new encryption key if the data folder is empty
# allow usage of all builtin modules
# tunnel for web hooks. we run n8n on pm2 and behind reverse proxy - nginx.
# Allow usage of external npm modules in function nodes.
# example
# n8n install moment
# n8n install lodash
# export NODE_FUNCTION_ALLOW_EXTERNAL=moment,lodash

And a production.json

    	"database": {
            "type": "postgresdb",
            "postgresdb": {
    			"host": "dns.eu-central-1.rds.amazonaws.com",
    			"password": "pwd",
    			"port": "5432",
    			"user": "user"
    	"generic": {
    		"timezone": "Europe/Berlin"
    	"security": {
    		"basicAuth": {
    			"active": true,
    			"user": "user",
    			"password": "pwd"
        "executions": {
            "saveDataManualExecutions": true

The idea is to source the terminal, with production.sh.

But somehow the configurations are not set, meaning the web app is left open - the basic security doesn’t work, no database is created at Amazon RDS.

  1. Can someone spot the problem here?
  2. Also I found out that not all configurations are possible via the json file. Is this intentional, and is there a plan to have everything in that file.
  3. Is there a way to check the current configuration n8n is using from the command line? Maybe print it at the start up, or have a cli command. [Could be a feature request if this doesn’t exist]

Hey @abcdefghiraj. Welcome to the community!

This is very exciting that you are going to use n8n in your production environment! Very cool!

I’ll keep coming back to this throughout the day a s a have a few minutes here and there.

First thing to double check is the environment variables in the production.sh script. I may be wrong but I believe that when variables are executes in a BASH script like yours was here (e.g. N8N_CONFIG_FILES=$HERE/production.json, these variables are only available to the present session (I’m assuming you are using SSH) and would not be active if you logged out and back in. This is also the case with the PM2 service which technically has its own session.

I believe to resolve these issues, you may need to use the export command in front of these variables to make them available to other sessions. They would also have to be executed prior to PM2 starting so that it is using all of the correct variables and configuration files.

Give that a look and I’ll try to come back to this again later today.

Hello @Tephlon ! Thanks for the reply. Yes this is partially the answer to the problem.
To quote -

My use case was to automatically configure n8n to pick up it’s data folder, the backend url for the app and other configurations from a json file that may change over time, and deployments. Hence the above setup.
pm2 allows defining tasks in a js file as mentioned on their website.

const mainUrl = “https://n8n.example.com”;

module.exports = {
apps : [{
name : “n8n”,
script : “n8n”,
env: {
“NODE_ENV”: “development”,
env_production : {
“NODE_ENV”: “production”,
“N8N_CONFIG_FILES”: __dirname + “/production.json”,
“N8N_USER_FOLDER”: __dirname + “/data”,
“N8N_CUSTOM_EXTENSIONS”: __dirname + “/extensions”,
“VUE_APP_URL_BASE_API”: mainUrl + “/”,
“WEBHOOK_TUNNEL_URL”: mainUrl + “/”
}, {
name: “certbot-renew”,
script: “certbot renew --quiet”,
cron_restart: “0 12 * * *”,
autorestart: false

You save this file as n8n.config.js and run it as pm2 start n8n.config.js --env production

Additionally the above file also has a cron job to refresh let’s encrypt certificates. With a js file in place, the possibilities are infinite.

  1. You can have individual modules which you can build before launching. You can pull modules from your repos just before deployment to make sure they always stay updated.
  2. You can, like me persist the encryption key, so deployments across changing servers will still allow you to use the same credentials.
  3. The data folder could be pre populated here, be it any db. [You will first need to have the initial tables created]. But this can help your versioning needs.