@Neiluj
I would welcome input from a member of the team on this.
Docker is intended to run a single process in a single container. When you want to run multiple services, you run multiple containers.
This is where you (typically) would use some kind of tool to orchestrate or compose those containers. For example, a docker-compose.yml will define a set of services, and how they connect and interact with each-other.
Cloudron is designed to host singleton containers. Unlike industrial-scale platforms as a service, it provides limited tooling for how to define connections to other services. The manifest allows you to connect to the services that exist; for example, I can say "connect to the Cloudron-provided Postgres server." However, I have no way to say "I have chosen to run an S3 server/Minio at location X, and please use it." As a result, it puts a significant burden on the user. Further, there is no way within the package to say "this should not boot if that service is not present." You have to write custom code in order to provide that logic.
Further, the Docs app itself wants to run multiple services. The frontend is separate from multiple backends in their design. The app itself has orchestration concerns and considerations.
So while I appreciate people saying "but it is all there!," we're not discussing what is required to make this a production-grade package.
You have to pull the codebase.
Study how it wants to be run, and decide how it can be run in Cloudron.
Write a custom build/containerization script for the app, compressing multiple services (that want to be in multiple containers) into a single container.
Write custom code to make sure external services that are not part of the Cloudron PaaS are present, and fail gracefully/in a way that a non-expert user can debug, so that they can add those services and connect them to the app.
Make this all automated and testable.
Maintain all of this while upstream rapidly evolves.
I'm forgetting things, I'm sure. I estimate 80-120h of work in this, and it is essentially devops work. It should bill at $85+/hour. Further, I'm notorious for underestimating how long it takes to develop features by a factor of 2x-4x. So, I think this is work worth at least $8K-$12K---to say nothing of having to maintain the package, against a large, fast-moving target. (And, while it is open source, governments tend to be very careful about accepting changes from third parties, because there are significant security and compliance burdens they must bear.)
Maybe I'm just accustomed to deployments in Ansible and Terraform, and am overstating the difficulty of this deploy. However, my experience is that when a system is designed to run one way, and you want it to run some other way, there's significant work involved.
So, in return, please forgive my ignorance. I may be misunderstanding things about packaging for Cloudron, and you may be right: this may be easier than I think.
I've started poking at a package for Planka to refresh myself on packaging, because it is a singleton Node app that only has Postgres as an external dependency. It is an example, in my mind, of an app that fits the Cloudron model perfectly. However, anything that wants orchestration beyond the core services Cloudron provides---especially when some of those services are custom components internal to the application itself---is, in my mind, significantly more effort.
