Cloudron Forum

Repo has been updated to include the following:

• split the Dockerfile into Dockerfile.cloudron and start.sh to match Cloudron app standards
• built-in LDAP auth

I've tested backup,restore and package upgrade.

https://github.com/jsonsmth/node-red-docker-cloudron

Thanks!

I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...

Here's a working config sample for Digital Ocean Spaces. Add the following entries in the env.sh and restart the Typebot app:

export S3_ACCESS_KEY=<YOUR DO ACCESS KEY>
export S3_SECRET_KEY=<YOUR DO SECRET KEY>
export S3_BUCKET=<YOUR BUCKET NAME>
export S3_ENDPOINT=nyc3.digitaloceanspaces.com
export S3_REGION=US
export S3_PORT=443

There are basically two apps in one with Typebot. There's the "builder" app which is the admin interface used to create and manage bot flow (this has the auth tied to it), and the "viewer" app, which is where published bots can be viewed by the public. I don't think you can add auth to the viewer URLs.

I just went into Digital Ocean and configured the CORS policy as it states. There's a gui for that:

Then I had to configure the ACL using s3cmd. It was tedious, but once done it just works forever.

@girish Ok, I understand a bit more about the Cloudron build process now. I have updated my Dockerfile.cloudron and moved the repo here:

https://github.com/jsonsmth/node-red-docker-cloudron

The updated build process stores all app code in /app/code and only the user-specific data (including user node_modules) in /app/data.

I have updated the repo here with built-in LDAP auth:

https://github.com/jsonsmth/node-red-docker-cloudron

@nebulon Yes, that fixed it for me.

@baptistearno Man, this is so great. Looks like a lot of work was put in. Awesome job, and thanks for the effort!

@robi Cloudron customizations are in the docker-custom folder

https://github.com/jsonsmth/node-red-docker

Feedback is welcome as this is my first foray into Cloudron app customization.

@girish Also, I think we're following along with the recommended method for preserving user data within the app:

https://github.com/jsonsmth/node-red-docker-cloudron#managing-user-data

@Aizat Thanks for mentioning this awesome software! Someone has pinged the author about creating a Cloudron app. Hopefully it will happen...

https://github.com/baptisteArno/typebot.io/issues/30

Been a while since I built the Docker version of Node-RED for Cloudron, but it worked with Cloudron LDAP auth when I built it. My method had a single admin user that can access all Node-RED flows, so there's no concept of permissions. That works fine for me, but might not for others. I'd be willing to revisit and update my method to the latest Node-RED version to make sure everything still functions within Cloudron from a backup/restore perspective and with LDAP auth. I know @hendrikvl recommended using the npm approach vs. Docker approach, so it really depends on your needs.

I recently noticed I had lost my test notes logged into the Memos app. I didn't put two and two together, but it must have been upgrade-related too.

@nebulon One minor issue when using the OpenAI integration in Typebot on Cloudron. It was covered in the Typebot issues on Github, but might be worth noting here as well. I had to manually change the value in the .encryption_secret file.

@staypath Continuing my conversation with myself

Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick:

[sshd]

port    = ssh
#logpath = %(sshd_log)s
#backend = %(sshd_backend)s
backend = systemd
enabled = true
maxretry = 1
bantime = 14d

Here's a similar idea that has the hardware part mostly figured out:

https://wiki.debian.org/FreedomBox

https://wiki.debian.org/FreedomBox/Hardware

@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules

I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!

I had a similar problem recently. Here's what I had to do in order to be able to programmatically update DNS records for a domain in Google Cloud DNS:

1. verify domain ownership: https://cloud.google.com/endpoints/docs/openapi/verify-domain-name. I did this by inputting a special DNS TXT record into DNS for the domain.

2. in my case, I was using a Google Cloud Service Account with Terraform (not Cloudron) to modify DNS records in Google Cloud DNS, so in additional to verifying domain ownership, I had to actually add the Service Account I created as a verified owner of the domain as well.

After doing these two things, I was able to programmatically update DNS records for the domain using the Service Account.

So, assuming you've created a Service Account at Google, given it the "DNS Administrator" role, and added the Service Account email as a verified owner of the domain, you should be good to go. I just tested it with my Cloudron and it all worked. I'm attaching a screenshot of the Google domain verification screen showing where I added the Service Account as a domain owner. Hope this helps.

@girish Thank you for the recommendation. I have tried on another bare metal server running Docker and I am able to access the external host IP from the Docker container. This is clearly a network issue with the host where I have Cloudron installed.