Yep, that worked!

@humptydumpty said in Publish an Official App Packaging Roadmap: As for app packaging, if I’m not mistaken, Cloudron staff take over and handle any future updates if it’s added to the App Store. I don’t expect every niche app will get adopted but the highly voted/starred apps that fill a gap in CR’s ecosystem will have a higher chance. CR could enhance/simply how custom repos/apps are added. Some of the regulars on here have shared their own packaged apps, but the process isn’t clear to me yet. That’s something worth looking into though. Sigh, too much to do and not enough time! That's the main difference to platforms like Yunohost, where you have a ton of user packaged apps.... - that don't work, break, become unmaintained etc.

Wow thanks @nebulon . I think it would have been necessary one day or another with the current AI hype. By the way I'd be glad to share my "cloudron packaging prompt engineering" techniques some when. I'll make a second try with another app, I am thinking appsmith

ok. thanks for the fast answer.

@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.

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!

Thank you for the detailed response! Since this app doesn't run the LLM itself, the system requirements are less heavy. But wouldn't everything that wasn't attached to Cloudron just run inside the container? I mean, let's say I write a dockerfile for this app, but "forget" to use the postgres addon of cloudron. Wouldn't the app still run, but with the database inside the app, so it would be overwritten upon updating? Other than that, this app seems to have a sandbox container and one for vector databases, which couldn't be rebuilt easily in Cloudron.

@girish To make it more clear, I have made a template repository with all the files and scripts I usually use for my Cloudron apps. In the future, we might benefit from adopting such a strategy for the Cloudron CLI init script by using these files as a template/starter Cloudron app project. It'd make maintenance easier, more uniform, and make the process less daunting for new app devs. https://github.com/Lanhild/starter-cloudron

@Lanhild yup, we already started using multi-stage builds by now. For app store, you have to pin the images though. Using ":latest" is not good will have to be changed.

Got it. Thanks for the answer!

@girish scroll and copy > chatgpt