Someone more familiar with packaging Cloudron apps would be able to answer better than me. However, I find that whenever a docker-compose.yml is involved, it is probably hard to move the app to Cloudron.
https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/docker-compose.yml
In this case:
It wants nginx. That might be avoidable, or it might be serving static assets/code for the app.
It wants minio. This could probably be accommodated by requiring users to run minio on their Cloudron before installing this.
It wants postgres, which might be able to be leveraged from the internal stack.
It wants redis. Again, possibly from the default stack... I can't remember.
gotrue is an auth component from supabase. This will need its own container, and may (or may not) play nice with the SMTP/OAuth running on Cloudron.
appflowy_cloud is the hosted app. It wants its own container, and configuration information for all of the services included.
admin_frontend has its own Dockerfile. I haven't looked. Looks like more things.
ai. I have no idea. It looks like it wants some kind of OpenAI. This is getting heavy in terms of resources.
appflowy_history is... another Dockerfile. Looks like a rust application that has been Dockerized.
The problem, I think, is that Cloudron assumes/is structured such that applications run as single containers. The compose is suggesting that this application has a number of independent components. Perhaps those could be bundled up/run separately... but, it might be a real trick to make work.
This isn't to say it isn't possible, but that's what I see that needs to run, and it isn't clear to me that this is an easy app architecture to move over to Cloudron. YMMV, etc.
