As long as you don’t have any conflict on resources, no problem (Captain Obvious inside 
).
Apart from the obvious disk/CPU/RAM, the tricky part is network, especially ports : 80(HTTP) and 443(HTTPS) are handled by the Dockerized NGINX (I excluded other ports like SMTP, IMPAP, etc because there are only web apps in your list).
From there you have 2 solutions:
- buy an additional public IP address (can be managed by the existing DNS domain), and use it for your supplemental apps, installing them as you want
- run your apps in Docker, either from Hub or from yourself, and add entries in NGINX reverse proxy for them
Whatever you choose, of course you’ll have to add DNS sub-domain entries, SSL certificates, … But it’s not relevant for this subject. However, selfhosted /e/ Cloud can help with certificates 
NB 1 : method 2 is safer, as you’ll benefit from NGINX reverse proxy protection for your apps, along with centralized logging (useful for tools like CrowdSec, currently experimenting on this one).
NB 2 : you may also benefit from the MariaDB, Redis Docker engines integrated with /e/ Cloud 
I documented a simple app some time ago : |HowTo] Add a webapp as a sideload of /e/ self-hosted cloud (some details may not be up to date, but the method is still valid).
I recently installed Guacamole (yes, I love 
), beside of some other web apps, onto my /e/ Cloud. I could share details with you.
I got no major problem with my Docker apps when upgrading /e/ Cloud, as all necessary configuration was externalized in Docker volumes and .env file.
Of course, method 2 implies some extra work, but this is compensated by the ease of administration and the availability of resources provided by /e/ Cloud.