{"id":22160512,"url":"https://github.com/rozek/node-red-within-express","last_synced_at":"2025-07-26T09:31:42.418Z","repository":{"id":40515267,"uuid":"401287369","full_name":"rozek/node-red-within-express","owner":"rozek","description":"embedding Node-RED within a Server built with Node.js and Express","archived":false,"fork":false,"pushed_at":"2023-04-25T12:53:35.000Z","size":311,"stargazers_count":20,"open_issues_count":0,"forks_count":6,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-04-15T15:07:51.604Z","etag":null,"topics":["express-js","node-red","web-server"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rozek.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-08-30T09:29:28.000Z","updated_at":"2024-01-17T11:55:30.000Z","dependencies_parsed_at":"2022-06-29T18:24:32.992Z","dependency_job_id":null,"html_url":"https://github.com/rozek/node-red-within-express","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rozek%2Fnode-red-within-express","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rozek%2Fnode-red-within-express/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rozek%2Fnode-red-within-express/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rozek%2Fnode-red-within-express/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rozek","download_url":"https://codeload.github.com/rozek/node-red-within-express/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":227668775,"owners_count":17801513,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["express-js","node-red","web-server"],"created_at":"2024-12-02T04:08:24.233Z","updated_at":"2024-12-02T04:08:24.922Z","avatar_url":"https://github.com/rozek.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# node-red-within-express #\n\nThis repository contains an HTTP(S) server based on [Node.js](https://nodejs.org/en/) with [Express.js](http://expressjs.com/) including an embedded [Node-RED](https://nodered.org/) instance.\n\nIts intended purpose is to provide a very easily maintainable server for development and test of web and REST service prototypes.\n\n\u003e Just a small note: if you like this work and plan to use it, consider \"starring\" this repository (you will find the \"Star\" button on the top right of this page), so that I know which of my repositories to take most care of.\n\n## Features ##\n\nThe implemented server has the following features:\n\n* **HTTPS with optional HTTP-to-HTTPS Redirection**\u003cbr\u003ethe main server handles HTTPS only as it is becoming increasingly difficult to deliver pure HTTP content to browsers (even locally). If desired, an additional auxiliary HTTP server may be started which redirects incoming requests to its HTTPS counterpart\n* **Proxy Support**\n* **Support for \"self-signed\" or \"Let's Encrypt\" Certificates**\u003cbr\u003efor local tests, it may be sufficient to generate self-signed certificates (instructions can be found below). For public tests, the server also supports certificates generated by [\"Let's Encrypt\"](https://letsencrypt.org/)\n* **Support for \"virtual Hosts\" and Subdomains**\u003cbr\u003ethe server may optionally support \"virtual hosts\" and serve multiple domains (including subdomains) simultaneously. In this case, each domain will be mapped to an individual file system subtree in order to isolate the domains from each other\n* **\"www\" Subdomains**\u003cbr\u003eif desired, \"www\" subdomains can be mapped to their original domain (since they usually serve the same content anyway)\n* **embedded Node-RED runtime**\u003cbr\u003eincoming requests will first be compared to the entry points given by \"HTTP in\" nodes - and their flows be executed whenever the URL paths match (if \"virtual hosts\" are to be respected, all these entry points become domain-specific and their paths must therefore be prefixed by the domain they belong to). Requests not matching any \"HTTP in\" node entry points will then be used to serve static files from the file system (or generate a 404 response if no matching file could be found)\n* **embedded Node-RED editor**\u003cbr\u003ethe embedded Node-RED editor is generally protected by \"basic HTTP authentication\": for that purpose, the server always comes with a \"User Registry\" which already contains a single user (named \"node-red\" with the initial password \"t0pS3cr3t!\") who is allowed to access the Node-RED editor\n* **Path-specific static File Protection**\u003cbr\u003emost static files on this server may be available to the public - but perhaps not all of them. For that purpose, this server allows to specify which files should only be available to specific users\n* **User Registry with PBKDF2 hashed Passwords and Role Support**\u003cbr\u003ethe list of registered users is stored in a JSON file with passwords saved as PBKDF2 hashes with random salt. While the server itself does not contain any user management, such a feature may easily be added as a Node-RED flow - although, in fact, a simple text editor is already sufficient to add new users, change existing ones or remove obsolete users\n* **Path-specific CORS**\u003cbr\u003e\"Cross-Origin Resource Sharing\" may be configured for complete sites as a whole or for specific resource paths with any desired granularity\n* **configurable \"Content Security Policies\"**\u003cbr\u003ethe server is secured using [Helmet](https://github.com/helmetjs/helmet) with a configuration option for specific \"Content Security Policies\"\n* **standard-compliant Logging**\u003cbr\u003eaccess logging is done using [morgan](https://expressjs.com/en/resources/middleware/morgan.html). Logs may be written into a file either in \"standard Apache common log format\" or any other format\n\n## Installation and Use ##\n\nYou may easily install and run this server on your machine.\n\nJust install [NPM](https://docs.npmjs.com/) according to the instructions for your platform and follow these steps:\n\n1. either clone this repository using [git](https://git-scm.com/) or [download a ZIP archive](https://github.com/rozek/node-red-within-express/archive/refs/heads/main.zip) with its contents to your disk and unpack it there \n2. open a shell and navigate to the root directory of this repository\n3. run `npm install` in order to install the server\n\n### Preparing the first Start ###\n\nFor a quick start, the server comes preconfigured for two different use cases:\n\n* ***without* virtual hosts processing**\u003cbr\u003ethis variant does not require much preparation and is ideal for initial experiments\n* ***with* virtual hosts processing**\u003cbr\u003ethis variant requires a bit of preparational work but may be used to test installations serving multiple domains\n\n#### Preparing a Server *without* virtual Hosts Processing ####\n\nUsing HTTPS to access servers with self-signed certificates cause warnings in most browsers, other tools may even refuse to work. In many browsers, it is sufficient to follow the presented instructions and accept the \"malicious\" certificate against all warnings (which is safe, since you created the certificate yourself). For other tools, it may be better to add the certificate to the system's list of trusted certificates.\n\nYou will have to accept the certificate for `localhost` when you start your server and navigate to one of its pages for the first time. However, the configured exception will only last for a few minutes and will then have to be repeated.\n\n\u003e Chromium-based browsers (such as Chrome or Microsoft Edge) offer a special flag which automatically accepts certificates for `localhost`: just enter `chrome://flags/#allow-insecure-localhost` (or `edge://flags/#allow-insecure-localhost`) into the browser's address list, press Enter and activate the flag on the page you will be shown\n\n#### Preparing a Server *with* virtual Hosts Processing ####\n\nUsing HTTPS to access servers with self-signed certificates cause warnings in most browsers, other tools may even refuse to work. In many browsers, it is sufficient to follow the presented instructions and accept the \"malicious\" certificate against all warnings (which is safe, since you created the certificate yourself). For other tools, it may be better to add the certificate to the system's list of trusted certificates.\n\nYou will have to accept the certificate for `local-server.org` when you start your server and navigate to one of its pages for the first time. However, the configured exception will only last for a few minutes and will then have to be repeated.\n\nIn order to be able to directly navigate to `localserver.org` and its subdomains, you will have to append the following entries to the file `/etc/hosts` (under Windows, this file is found at `%windir%\\system32\\drivers\\etc\\hosts`):\n\n```\n  127.0.0.1 local-server.org\n  127.0.0.1 www.local-server.org\n  127.0.0.1 webapp.local-server.org\n```\n\nAny text editor will do the job.\n\n### First Experiments ###\n\nOn UNIX-like systems, the available start scripts should be made executable in order to simplify their invocation:\n\n```\nchmod +x startServer*\n```\n\nUnder Windows, the first line of these scripts (the \"shebang\" line) may have to be deleted instead.\n\nNow you are ready to start your server: within a terminal window, navigate to the folder containing this repository and either enter\n\n```\n./startServerWithDomains\n```\n\nor\n\n```\n./startServerWithoutDomains\n```\n\ndepending on the scenario you want to test.\n\nAs soon as the server has started up (it reports this process on stdout) you may use a browser of your choice and navigate to `localhost:8443` or `local-server.org:8443`, resp. As a result, the browser should show you a simple web page with a small image and the server should have logged two requests on the console. This experiment proves that static files are delivered properly\n\nGo further and navigate to `localhost:8443/hello-world` (or `local-server.org:8443/hello-world`, resp.). The browser should now show the text `Hello, World!` - a text that has been generated by Node-RED.\n\nNext, navigate to `localhost:8443/show-request` (or `local-server.org:8443/show-request`, resp.). The browser should now show the text `(see Node-RED debug console)` which reminds you to open the Node-RED editor and have a look into its debug window.\n\nThus, open a new tab in your browser and navigate to `localhost:8443/.Node-RED/Editor` (or `local-server.org:8443/.Node-RED/Editor`, resp.). Instead of showing anything, your browser should first ask you to authenticate yourself: enter `node-red` as your user name and `t0pS3cr3t!` as your password (exactly as shown here). If you mistyped anything, the browser will present the authentication dialog again. Otherwise, the Node-RED editor will be opened and you will see a workspace with the initial set of flows that came with this server.\n\nOpen the debug output, switch back to the previous browser tab and reload the page you requested before (either `localhost:8443/show-request` or `local-server.org:8443/show-request`). Switch back to the Node-RED editor and inspect the debug window: you should now be able to inspect the request your browser sent to the server.\n\nYou are welcome to test that `show-request` with the HTTP methods `PUT`, `POST`, `PATCH` and `DELETE` as well - e.g., using tools like [cURL](https://curl.se/) or [Postman](https://www.postman.com/).\n\nAs usual, all requests should have been logged both on the console and in a file called `localhost.log` (or `local-server.log`, resp.) within subfolder `logs`.\n\n## Invocation Parameters ##\n\nThe server in this repo has been implemented as a Node.js script and can be invoked as follows\n\n```\nnode WebServer.js [options] \u003cfile-root\u003e [\u003cconfiguration-folder\u003e [\u003clog-folder\u003e]]\n```\n\nwith the following arguments:\n\n* **`\u003cfile-root\u003e`**\u003cbr\u003especifies the root folder (relative to the server's current working directory) of all deliverable static files. By default, this is a subfolder of the current working directory called `public`\n* **`\u003cconfiguration-folder\u003e`**\u003cbr\u003especifies the folder (relative to the server's current working directory) where configuration files (such as the list of registered users) are found. By default, this is the current working directory itself\n* **`\u003clog-folder\u003e`**\u003cbr\u003especifies the folder (relative to the server's current working directory) into which the log file is written. By default, this is a subfolder of the current working directory called `logs`\n\nThe following options are supported:\n\n* **`--server-port \u003cport\u003e`**\u003cbr\u003especifies the TCP port at which to listen for incoming HTTPS requests. The default is `8443`\n* **`--redirection-port \u003cport\u003e`**\u003cbr\u003eif provided, this option activates HTTP-to-HTTPS redirection and specifies the TCP port at which to listen for incoming HTTP requests\n* **`--proxy \u003cproxy\u003e`**\u003cbr\u003eactivates and configures proxy support. Consider the [Express.js documentation](https://expressjs.com/en/guide/behind-proxies.html) for a list and explanation of actually allowed values\n* **`--domain \u003cdomain\u003e`**\u003cbr\u003especifies the primary domain of this server. It should be the \"common name\" (CN) of the associated server certificate and also appears in the log file name. If virtual hosts are given as well (even if the list is empty), the primary domain is automatically added to that list\n* **`--virtual-hosts \u003cvirtual-hosts\u003e`**\u003cbr\u003eactivates virtual hosts processing and configures the domains to handle. The given argument may either be an empty string (`\"\"`) or a string containing a comma-separated list of internet domains. All mentioned domains should also be specified as \"subject alternative names\" (SAN) in the server certificate\n* **`--allow-subdomains`**\u003cbr\u003eif specified, all subdomains of the given primary domain and virtual hosts are processed as well. In this case, the server certificate should also contain \"subject alternative names\" (SAN) with wildcards of the form `*.\u003cdomain\u003e`\n* **`--ignore-www`**\u003cbr\u003eif specified, subdomains of the form `www.\u003cdomain\u003e` are not treated as a separate subdomain but mapped to their main `\u003cdomain\u003e`\n* **`--cert-folder \u003cfolder\u003e`**\u003cbr\u003especifies the folder where to find server certificates. By default, this is a subfolder of the server's current working directory called `certificates`\n* **`--pbkdf2-iterations \u003ccount\u003e`**\u003cbr\u003especifies the number of iterations when computing PBKDF2 hashes. Default is 100000\n* **`--log-format \u003cformat\u003e`**\u003cbr\u003especifies the format in which log entries are written into a file. Consider the [morgan documentation](https://expressjs.com/en/resources/middleware/morgan.html) for a list and explanation of permitted settings. Default is `common`\n\nIf everything works well, the server reports its start-up and logs all incoming requests on `stdout`\n\n### Configuring Domains and Virtual Hosts ###\n\nOn a \"production system\", usually no special precautions need to be taken to run this server.\n\nSynthetic tests with virtual hosts on a local machine, however, should be prepared as follows:\n\n* generate self-signed certificates for all domains under test:\u003cbr\u003efolder `certificates` contains a file `local-server.org.cnf` which can be used for that purpose\n  * copy this file and name the copy `\u003cprimary-domain\u003e.cnf` where \"\u0026lt;primary-domain\u0026gt;\" should be replaced by the name of your primary domain\n  * create a subfolder with the name of your primary domain\n  * open `\u003cprimary-domain\u003e.cnf` in a text editor of your choice\n  * replace `local-server.org` with your primary domain (both behind `CN =` and `DNS.1 =`)\n  * append additional domain names as further `DNS.#` entries at your will\n  * save this file and run the following command\u003cbr\u003e`openssl req -x509 -nodes -newkey rsa:4096 \\`\u003cbr\u003e`-keyout \u003cprimary-domain\u003e/privkey.pem \\`\u003cbr\u003e`-out \u003cprimary-domain\u003e/fullchain.pem \\`\u003cbr\u003e`-days 3650 -config \u003cprimary-domain\u003e.cnf`\u003cbr\u003e(again, after replacing \"\u0026lt;primary-domain\u0026gt;\" with the name of your primary domain)\n* append an entry for each desired domain to `/etc/hosts`. Each entry must have the form\u003cbr\u003e\u0026nbsp; \u0026nbsp; `127.0.0.1 \u003cprimary-domain\u003e`\u003cbr\u003ewildcards are not allowed\n* modify the script `startServerWithDomain` by replacing `local-server.org` with the name of your primary domain and - if need be - adding a `--virtual-hosts` option with a comma-separted list of additional domain names (subdomains of your primary domain do not have to be mentioned explicitly, the option `--allow-subdomains` already covers them)\n\nYou may now run `startServerWithDomain` and navigate your browser to any of the configured domains (don't forget to specify your server's port number unless it is a standard one)\n\n## Embedded Node-RED Instance ##\n\nThe embedded Node-RED instance comes with two sets of flows for initial \"smoke tests\": one for a server *with* virtual host processing and one *without*.\nA GET request to `/hello-world` simply responds with a \"Hello, World!\" message, GET, PUT, POST, PATCH and DELETE requests to `show-request` dump the contents of any incoming message to the Node-RED debug window.\n\n![initial Flow Sets](initialFlows.png)\n\nBoth flow sets are welcome to be removed and replaced with more meaningful ones.\n\nFor your own flows, the following server parameters are copied into the global context:\n\n* **`ServerPort`**\u003cbr\u003econtains the port number at which this server listens for incoming requests\n* **`RedirectionPort`**\u003cbr\u003eis either `undefined` or contains the port number of the redirection server\n* **`behindProxy`**\u003cbr\u003eis either `false` or contains the setting given in command option `--proxy`\n* **`primaryDomain`**\u003cbr\u003eis either `undefined` or contains the primary domain name for this server\n* **`virtualHosts`**\u003cbr\u003econtains a (potentially empty) JavaScript array with the names of all domains handled by this server\n* **`allowSubdomains`**\u003cbr\u003eis `true` if subdomains are allowed or `false` otherwise\n* **`PBKDF2Iterations`**\u003cbr\u003econtains the number of PBKDF2 iterations calculated when generating password hashes\n* **`FileRoot`**\u003cbr\u003econtains the absolute path of the root folder containing all static files which may be delivered by this server\n* **`ConfigRoot`**\u003cbr\u003econtains the absolute path of the folder containing any server configuration files\n* **`LogRoot`**\u003cbr\u003econtains the absolute path of the folder into which logs are written\n* **`CORSRegistry`**\u003cbr\u003econtains the JavaScript array with all CORS rules. The array is copied \"by reference\" which means that changes in this array immediately affect the server itself (no server restart required)\n* **`UserRegistry`**\u003cbr\u003econtains the JavaScript object with all registered users. The object is copied \"by reference\" which means that changes in this object immediately affect the server itself (no server restart required)\n\n## User Registry ##\n\nThe server comes with a file `registeredUsers.json` which contains all \"registered users\" of this server.\nInitially, it contains a single user named \"node-red\" with password \"t0pS3cr3t!\" who is needed to access the embedded Node-RED editor.\nNew users may be added and existing users changed or deleted at will with a simple text editor.\n\n`registeredUsers.json` contains the JSON serialization of a JavaScript object with the following format:\n\n* the object's property names are the ids of registered users\u003cbr\u003euser ids have no specific format, they may be user names, email addresses or any other data you are free to choose - with **two important exceptions: user ids must neither contain any slashes (\"/\") nor any colons (\":\")** or some authentication or user management mechanisms (like those described in [node-red-authorization-examples](https://github.com/rozek/node-red-authorization-examples) or in the [node-red-user-management-example](https://github.com/rozek/node-red-user-management-example)) may fail\n* the object's property values are JavaScript objects with the following properties, at least (additional properties may be added at will):\n  * **Roles**\u003cbr\u003eis either missing or contains a list of strings with the user's roles. There is no specific format for role names - just the role `node-red` has a special meaning: users with this role are allowed to access the embedded Node-RED editor\n  * **Salt**\u003cbr\u003econtains a random \"salt\" value which is used during PBKDF2 password hash calculation\n  * **Hash**\u003cbr\u003econtains the actual PBKDF2 hash of the user's password\n\nThe server will not start if file `registeredUsers.json` is missing or does not have valid JSON content.\n\nUsers without proper `Salt` and `Hash` values can not authenticate themselves. Those without role `node-red` can not access the embedded Node-RED editor\n\n\u003e Nota bene: Node-RED *flows* work independent of the embedded editor's accessability!\n\n### Generating \"Salt\" and \"Hash\" ###\n\nThis repo also contains a small utility called `generateSaltAndHash` which may be used to generate the \"Salt\" and \"Hash\" values for entries in the user registry.\n\nFrom within the folder containing the repository, it is invoked with\n\n```\n./generateSaltAndHash\n```\n\nThe script will ask for a password and - as soon as the password has been entered - generate salt and hash values and display them on the console. From there, these values may be copied into the clipboard and added to `registeredUsers.json`.\n\nBy default, `generateSaltAndHash` assumes a PBKDF2 iteration count of 100000. If another count is desired, the utility should be invoked with\n\n```\n./generateSaltAndHash pbkdf2-iterations \u003ccount\u003e\n```\n\n## Static File Protection ##\n\nBy default, all static files are considered \"public\", i.e. available to any visitor without prior authentication.\n\nIf desired, however, it is possible to specify, which files should only be available to specific users (who then have to authenticate themselves before they are allowed to access these protected files). Such rules can be specified in file `protectedFiles.json` which is found in the configured `\u003cconfiguration-folder\u003e`.\n\nThis file contains the JSON serialization of a JavaScript object with the following format:\n\n* the object's property names are regular expression (RegExp) patterns which are compared against any incoming URL path (including the domain name, if virtual hosts are to be processed) \n* the object's property values are strings which either contain a single asterisk (\"`*`\") indicating that any authenticated user may access, or a blank separated list with the names of those users who are allowed to access the matching file.\n\nThe example that comes with this server protects all files and folders whose names start with a dot (\".\") and (in the case of protected folders) their contents.\n\nThe server will not start if file `protectedFiles.json` is missing or does not have valid JSON content.\n\n## CORS Support ##\n\n\"Cross-Origin Resource Sharing\" ([CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)) instructs browsers to restrict resource access to specific domains. For this server, CORS behaviour can be specified in file `sharedResources.json` which is found in the configured `\u003cconfiguration-folder\u003e`.\n\nThis file contains the JSON serialization of a JavaScript array containing objects with the following format:\n\n* property `PathPattern` contains a regular expression (RegExp) pattern which is compared against any incoming URL path (including the domain name, if virtual hosts are to be processed)\n* property `OriginList` is either `null` (which acts as a placeholder allowing unrestricted resource sharing) or a JavaScript array containing the names (without protocols or port numbers) of all domains which are allowed to request the matching resource (whereas any domain not mentioned in this list is not allowed to access the resource)\n\nWithout any entries, browser settings apply (which are often quite restrictive)\n\nThe server will not start if file `sharedResources.json` is missing or does not have valid JSON content.\n\n## Content Security Policies ##\n\n\"Content Security Policies\" (CSPs) are a method for web servers to ask browsers for imposing certain restrictions when the delivered page is shown (and contained scripts executed). Carefully crafted, CSPs may reduce the effect of Cross-Site Scripting (XSS) and data injection attacks. Sloppyly chosen, the delivered web page will just not work as intended.\n\nConsideration of CSPs requires a modern browser (as this function is actually provided by the browser) and should always be tested with an eye on the browser's console (where CSP violations will be reported)\n\n\u003e European users may also use CSPs as another aid for guaranteeing the GDPR (or DSGVO) compliance of their web sites by permitting web pages to access only servers which are known for their GDPR compliance, and inhibiting access to any other unknown ones.\n\nFor this server, \"Content Security Policies\" can be entered in a file called `ContentSecurityPolicies.json` which is found in the configured `\u003cconfiguration-folder\u003e`. For technical reasons, the given CSPs apply to *all* delivered web pages and can not be specified per page.\n\nThis file contains the JSON serialization of a JavaScript object with the following format:\n\n* the object's property names are \"Content Security Policies\" (CSP) \"directives\"\u003cbr\u003esee [the documentation at MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) for a list and explanation of available directives\n* the object's property values are JavaScript arrays containing a list of policies for the given directive (see [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src) for a list and explanation of such policies)\n\nThe server will not start if file `ContentSecurityPolicies.json` is missing or does not have valid JSON content.\n\n## Logging ##\n\nThe server uses [morgan](https://expressjs.com/en/resources/middleware/morgan.html) for the formatting of log entries.\n\nTwo logs are written: a simplified one (which allows to monitor server operation) is written to `stdout`, an extended one into a file named after the configured primary domain (or `localhost`) within the configured `\u003clog-folder\u003e`.\n\nUnless this has been changed, the larger log file follows the \"standard Apache common log format\" and may be processed using standard log file analysis tools. Other log format may be configured with command option `--log-format \u003cformat\u003e`\n\n## License ##\n\n[MIT License](LICENSE.md)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frozek%2Fnode-red-within-express","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frozek%2Fnode-red-within-express","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frozek%2Fnode-red-within-express/lists"}