I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.

You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app

Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.

The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.

For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.

I had the same issue with a custom app I created. My solution was to include a webserver that runs in parallel via supervisord, although my custom app would not require it for its own functioning.
A sample of what this could look like is in the supervisor demo-app: https://git.cloudron.io/cloudron/tutorial-supervisor-app/
The webserver in there only returns a static page with status code 200, which is all you need to pass the health-check.

I would like to propose/discsuss the following: How about an option to bind additional Docker volumes for Cloudron apps?

My usecase is the following: As discussed several times in this forum, the built-in backup options of Cloudron are not so well suited for the rather large data directories of Nextcloud. Therefore, I would like to move the Nextcloud data to another volume (which is not included in the Cloudron backup) and change the nextcloud-config to use that as data directory. I would then take care of backing up that directory on the Cloudron host by myself.

I currently implemented that behaviour by creating a symlink of the data directory on the host. @tobru mentioned that in this post and asked how to include it in the backup. I explicitly went that way to exclude a folder from the backup. But that seems like misusing an implementational detail of the Cloudron backup, which might change at some point and should not be done on purpose. Thus my question to bind a custom folder as volume in the app-container.

I know that you plan to implement a per-app choice of tgz/rsync backup-options in one of the upcoming releases. That wouldn't really solve it for me though, as I use the Filesystem backup provider and would end up with an additional copy of my nextcloud data. (I use restic btw, to backup both the Cloudron backup-directory and the nextcloud data folder.)

@girish said in Node-RED - Flow-based programming for the Internet of Things:

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

Nice, as expected of any cloudron app email and db are auto-configured.
Both are not required to run Node-RED though. They are optional modules that can be used within flows that one wants to implement, but have no functionality for the core itself. Still, I thought that its useful to be able to access the functionality that Cloudron as a platform provides.

Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows?
I'm relatively new to Node-RED myself and can't tell with certainty. As far as I understand the documentation, one can differentiate between users and assign specific permissions for different methods of the API (create a flow, enable a module, etc.), but cannot differentiate between flows. Flows seem to be shared between users in any case. So it's not a real multi-user application, where each user can create their own flows. This post proposes to run multiple node-red instances if users shall be able to create independent flows.

When LDAP is implemented, who provides the login page? Is this part of some plugin?
The login page seems to be the default one provided by Node-RED. It is only the authentication-scheme which is plugged in through an extra module.

The LDAP-module does not seem to support different permissions though. Each user with valid credentials gets full permissions (see this line).

Just searched the forum for any news on 2FA and am happy that the discussion came up again. I would also endorse the proposal of PASSWORD;TOTP. Having no 2FA for some of the apps makes me somewhat nervous nowadays.
I totally understand that this is less than ideal from an UX perspective, but I don't see how it would hurt if admins can optionally enable it.

I only recently discovered, that cloudron uses a local unbound installation as DNS recursor and ignores DNS servers that were in /etc/resolv.conf before installing cloudron. Using unbound to include the local cloudron network, seems a good idea, but I am wondering whether using root DNS servers is necessary. (This is at least what happens on my machine, when resolving external hostnames: unbound queries its way down from the root DNS servers)

As an alternative to the root DNS servers I added a new config /etc/unbound/unbound.conf.d/forward.conf:

forward-zone:
        name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8

(Cloudflare and Google DNS servers just as an illustration, I used the ones from my VPS hoster)

Two questions/points for discussion on this:

1. Do you see any problems how this could interact with the local name resolution in an unintended way?

2. Would it be a good idea to generate such a config file as an optional step during the web-based Cloudron-setup?

The users page in the Cloudron panel has that setting labeled "Allow users to edit their name and email", which is also named profile lock in the manual.

When that checkbox is disabled (users are not allowed to edit), I noticed some strange behaviour: New users can be created, but they cannot set their password after using the invite link. What happens instead is the following: User clicks invite link, gets screen where to input password. After submitting that form the next screen "Your Account is ready, open dashboard" is shown. But after clicking open dashboard, one gets to the regular login screen. From there one cannot login with the newly setup credentials.

I checked in the box-database what happens: After creating the user, the new entry in the users-table seems correct. What is strange is that even the moment the "Your account is ready"-screen is shown, the password-field has not changed and the inviteToken is still there. There is no difference whether the profileLocked-parameter is included in the invite-URL or not.

After enabling the checkbox in the users page again, the setup works allright. Even with the old invite-link.

I could reproduce that behaviour on two different cloudron instances being on v7.0.4.

I also thought about that, since I would like to be able to access my scanned documents from Nextcloud as well.
I considered to use a separate volume as data exchange between paperless-ng and Nextcloud. On the Nextcloud side one could use the external storage-app to get /media/volumeXYZ "mounted" in the Nextcloud. The question is how to get the archive-folder of paperless-ng to that volume.

I currently see two options for that:
a) Configure paperless-ng to use the volume as media-root (PAPERLESS_MEDIA_ROOT in /app/data/paperless.conf). That way all folders thumbnails, originals and archive would be on the volume. But with the external storage-app one could make only of them (most likely the archive one) accessible from Nextcloud. Biggest disadvantage I see: Documents would have OCR on them, but are only accessible by ID from Nextcloud (no document types or tags).
b) Leave the media-root in /app/data as it is by default, but copy all files to the volume once they have been processed by paperless. That would most likely require a custom cronjob, but maybe there is also some post-processing option available in paperless? Disadvantage: even more tweaking necessary and duplicate storage requirements. Advantage I see with that option: One could implement something to include captions, tags or document types in the filenames, making files easily accessible from Nextcloud as well.

@hendrikvl Just wanted to report that I switched to volumes which are now implemented in Cloudron 6. I have the Nextcloud-config and apps in appsdata and a separate Nextcloud datadirectory mounted through a volume. Cloudron takes care of backing up appsdata and I backup the NC-datadirectory separately. Works like a charm.

Thanks for implementing that!

@girish Great, that you added support for custom cron-commands. I currently have a "cloudron exec" running as cron-job outside of an app, just because I was missing exactly this feature

@girish said in Node-RED - Flow-based programming for the Internet of Things:

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

Nice, as expected of any cloudron app email and db are auto-configured.
Both are not required to run Node-RED though. They are optional modules that can be used within flows that one wants to implement, but have no functionality for the core itself. Still, I thought that its useful to be able to access the functionality that Cloudron as a platform provides.

Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows?
I'm relatively new to Node-RED myself and can't tell with certainty. As far as I understand the documentation, one can differentiate between users and assign specific permissions for different methods of the API (create a flow, enable a module, etc.), but cannot differentiate between flows. Flows seem to be shared between users in any case. So it's not a real multi-user application, where each user can create their own flows. This post proposes to run multiple node-red instances if users shall be able to create independent flows.

When LDAP is implemented, who provides the login page? Is this part of some plugin?
The login page seems to be the default one provided by Node-RED. It is only the authentication-scheme which is plugged in through an extra module.

The LDAP-module does not seem to support different permissions though. Each user with valid credentials gets full permissions (see this line).

I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.

You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app

Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.

The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.

For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.

@plan-a The same applies for other settings, such as Webhook URL and message. They are emptied when logging in again.

I use a Hetzner storagebox via sshfs as backup provider and also have the issue with the volume being not mounted after reach reboot. Clicking the remount volume button solves it for me though. All previous backups are correctly listed after remounting.

Having to remount the volume manually is somewhat annoying though and I would appreciate a solution which solves the issue with the circular dependency on boot.

I had the same issue with a custom app I created. My solution was to include a webserver that runs in parallel via supervisord, although my custom app would not require it for its own functioning.
A sample of what this could look like is in the supervisor demo-app: https://git.cloudron.io/cloudron/tutorial-supervisor-app/
The webserver in there only returns a static page with status code 200, which is all you need to pass the health-check.

Thinking more about it, the option b) I considered above seems too much effort to implement. Creating a directory structure, including document types and everything, from information stored in the DB could lead to a usable result, but would require some tinkering on both sides. If one would invest that effort, why not create a Nextcloud App providing a custom external storage, which connects to the paperless-ng API (https://paperless-ng.readthedocs.io/en/latest/api.html). Such a solution would not depend on manual configuration of Cloudron volumes and could be used straight from Nextcloud. I wonder if there is anything like that out there already, but could not find anything related on a quick search.

@girish Ok, good to know that the fix is already there. Thanks!

The users page in the Cloudron panel has that setting labeled "Allow users to edit their name and email", which is also named profile lock in the manual.

When that checkbox is disabled (users are not allowed to edit), I noticed some strange behaviour: New users can be created, but they cannot set their password after using the invite link. What happens instead is the following: User clicks invite link, gets screen where to input password. After submitting that form the next screen "Your Account is ready, open dashboard" is shown. But after clicking open dashboard, one gets to the regular login screen. From there one cannot login with the newly setup credentials.

I checked in the box-database what happens: After creating the user, the new entry in the users-table seems correct. What is strange is that even the moment the "Your account is ready"-screen is shown, the password-field has not changed and the inviteToken is still there. There is no difference whether the profileLocked-parameter is included in the invite-URL or not.

After enabling the checkbox in the users page again, the setup works allright. Even with the old invite-link.

I could reproduce that behaviour on two different cloudron instances being on v7.0.4.

I also thought about that, since I would like to be able to access my scanned documents from Nextcloud as well.
I considered to use a separate volume as data exchange between paperless-ng and Nextcloud. On the Nextcloud side one could use the external storage-app to get /media/volumeXYZ "mounted" in the Nextcloud. The question is how to get the archive-folder of paperless-ng to that volume.

I currently see two options for that:
a) Configure paperless-ng to use the volume as media-root (PAPERLESS_MEDIA_ROOT in /app/data/paperless.conf). That way all folders thumbnails, originals and archive would be on the volume. But with the external storage-app one could make only of them (most likely the archive one) accessible from Nextcloud. Biggest disadvantage I see: Documents would have OCR on them, but are only accessible by ID from Nextcloud (no document types or tags).
b) Leave the media-root in /app/data as it is by default, but copy all files to the volume once they have been processed by paperless. That would most likely require a custom cronjob, but maybe there is also some post-processing option available in paperless? Disadvantage: even more tweaking necessary and duplicate storage requirements. Advantage I see with that option: One could implement something to include captions, tags or document types in the filenames, making files easily accessible from Nextcloud as well.

I only recently discovered, that cloudron uses a local unbound installation as DNS recursor and ignores DNS servers that were in /etc/resolv.conf before installing cloudron. Using unbound to include the local cloudron network, seems a good idea, but I am wondering whether using root DNS servers is necessary. (This is at least what happens on my machine, when resolving external hostnames: unbound queries its way down from the root DNS servers)

As an alternative to the root DNS servers I added a new config /etc/unbound/unbound.conf.d/forward.conf:

forward-zone:
        name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8

(Cloudflare and Google DNS servers just as an illustration, I used the ones from my VPS hoster)

Two questions/points for discussion on this:

1. Do you see any problems how this could interact with the local name resolution in an unintended way?

2. Would it be a good idea to generate such a config file as an optional step during the web-based Cloudron-setup?