@crazybrad I stand corrected. Cool beans.

ok. thanks for the fast answer.

@sebdev @cortex @robi @scooke @github-tijlxyz @jdaviescoates @timconsidine you might be interested in trying out this nostr package and maybe providing some feedback for nostrdev-com who kindly created it.

@mdc773 there is a video at https://forum.cloudron.io/topic/2843/read-first-before-starting-to-package-an-app which @fbartels made

Thanks for the reminder, I have updated that file now with the new base image.

@girish - Given that the only blocker (that I know of so far) is the TLD certificate availability, would it be a decent workaround to package this entire thing as an application, and then run a one-time command to symlink the TLD certificate into the application directory? This would allow the sys admin to choose which application deserves access to the TLD certificate, ensure the app always has access to the latest certificate, and work around the current limitation of apps not being able to request the TLD cert.

I think that is just the docker image and not the docker file - https://hub.docker.com/r/jacobmatrktippetts/monero-node

Maybe a temporary issue with your private docker registry or otherwise. Lets see if next time we have more info to work with.

I solved the port issue as well.
The problem occured when I tried to start an interactive shell, which counted as starting a second application inside the cloudron app, that's where the port conflict came from.

If someone else is working with Elixir on Cloudron, you can start an interactive shell like this:
/app/_build/prod/rel/APP/bin/APP remote

As a relatively new member of the Cloudron community (especially compared to @scooke) I can see both points of view. The current collection of apps is very eclectic, spanning both personal and business. And to a certain extent that reflects the wide range of our community - a strength.

I do not envy @girish and team trying to please all of us. It is both thankless and impossible. But one person's "must have" app is another person's "who cares". The danger is losing members if their needs are not met with the applications they need or want.

Perhaps having a simplified installation process would allow more people to customize their Cloudrons as desired. And yes, despite the warnings that you are on your own, I am sure that support questions will arise. And the spirit of the Cloudron team and the community to help will always prevail. As long as these questions are within reasonable limits, perhaps this will allow the platform to grow more valuable without being overwhelmed. I would suggest that custom-installed apps have its own topic area, especially if the results could be hidden from search engines to prevent prospective members getting the wrong impression about Cloudron's reliability per @scooke 's valid concerns.

Finally, I am personally interested in a business-oriented, custom-app platform where Dockerized applications can be hosted in a well-thought out and architected environment like Cloudron. We are exploring several ideas along these lines, including adding some private applications we have created, others we have paid to license, and some that are open source. And these systems would require incremental Cloudrons - helping to grow the revenue stream. In the end, that's the idea, isn't it...

@alex-uxlabsmx should work now. there were a couple of issues in the crontab:

'&' in the end of the cron line. this puts the command in the background. cronjobs are not run in background and instead run on a schedule. so, the '&' should be removed. 'source' command is a bash primitive. you have to wrap it in bash -c "source ... && anothercommand", for example

seems to work after that.

I am not familiar with how nestjs works during startup, but something tries to wholesale rm the /dist folder. I guess it tries to rebuild the app on startup? You may have to copy the app from read-only to /run first thing in start.sh and then start the app and not symlink the folder? Just a guess though.

Glad you got it sorted out!