I'm using Jellyfin in Cloudron but I kept Plex outside, on a dedicated (seed)box, where it works fine and lives along many other seedbox-type services closely integrated with each other and which at least are not impacted by Cloudron updates, with way more bandwidth than I can allow myself on my Cloudron. Also I prefer to keep Plex/*arr/Torrent related stuff apart from my business stuff on Cloudron.

@walski thanks, will take a look!

Right, we don't have any apps that run their own databases. In general, this won't work with backups/restore since one needs to take a proper dump of databases for it to be portable and consistent .

@makemrproper Use EspoCRM

@RedzzDragon I very much doubt this will ever be on Cloudron tbh

Why not n8n tho? It should be able to do the same.

Any hope at all?

I've just discovered AppFlowy and this app seems awesome ! Would love to see it in Cloudron. I'm a notion power user, and I can't wait to ditch notion. But as @jadudm said, seems like docker-compose based app are not easy to convert to a single dockerfile to work with Cloudron...

@rmpg should I sent you an invite to this forum's email ? Otherwise, if you drop a note to support@cloudron.io, we can send you an invite . I am told registration is currently closed because there is too much spam on GitLab .

BTW, I've been trying Readeck and it's pretty smooth. The closest I've found to a nice self hosted read-it-later app around

@JUVOJustin Any news on this topic? Would also be interested for mail testing purposes.

Even though the suggestion is a bit older and hasn't found any supporters yet, Cloudron still lacks server monitoring software! My primary concern would be to monitor other servers such as web or database servers. And in more depth than just uptime. As a nice side effect, the Cloudron server could perhaps also be monitored. A good list of features can be found at https://checkmk.com/product/server-monitoring-software: Scalable server monitoring software for Sysadmins and DevOps Ensure peak server performance for your infrastructure with the best server monitoring. Say goodbye to preventable outages, late nights, or weekend emergencies. Monitor any type of server (web, mail, database servers etc.) Flexible server monitoring through the use of more than 2,000 smart checks Easy-to-use configuration, auto-discovery and network mapping Native agents for Windows, Linux and many more operating systems Agentless monitoring with SNMP and TCP/UDP (FTP, LDAP, IMAP etc.) API-based checks based on HTTP/XML, SSH or TELNET Measurement intervals as short as <1 minute There is a Docker installation: https://docs.checkmk.com/latest/en/introduction_docker.html In addition is the Checkmk Raw Edition free and 100% open-source. See also https://github.com/Checkmk/checkmk

I did make some progress yesterday with Horilla. Had a "working" version with the latest state of: refusal of the media/ folder in its own web root Refused in sense of, did the initial setup uploaded my company logo, which got placed into the media/ folder but returned 404 They provide a Dockerfile which I abridged with the Cloudron base image and python uv. First time working styles and assets were missing, saw in the web console 404 for them. Then I noticed an error on start where it complained about folder staticfiles/ missing. So created it only to notice nothing changed only the startup error is now gone. Then I took a look at their own entrypoint.sh and found: python3 manage.py collectstatic --noinput What is this? What does it do? Documentation > /dev/null Did get some insight via: uv run manage.py collectstatic --help This collects all static files and places them in staticfiles/. So now I had styles and assets. Yay. So. It is documented that before running the server you need to run: python3 manage.py makemigrations python3 manage.py migrate Is this dynamic on every run or can this be static in the image /app/code/? It should be dynamic and static? 🤨 makemigrations sound like something you need to do before upgrading the software? migrate could be run on every app startup, if nothing needs to be migrated it should do nothing. This is all speculation since it is not documented. Now outside the installation wiki for Ubuntu in the main README.md there is this section about: Enable Translation with python3 manage.py compilemessages So this is static? Right? Ehhhh looked like no. Will need to investigate. It seems this app could also be highly customized by the user with css/scss. They are implementing dynamic styling => https://github.com/horilla-opensource/horilla/issues/658#issuecomment-2795889647 But as of now, I assume, this here is still valid https://github.com/horilla-opensource/horilla/issues/644#issuecomment-2760161068 Meaning, as of now, styling is done directly via: sass static/src/scss/main.scss static/build/css/style.min.css Meaning, a static file suddenly is dynamic. This is a big no no in the Cloudron app context. Either files are readonly or readwrite and then rw in /app/data/ or /run /tmp and are volatile. And now to another topic. There is a settings.py which much more undocumented stuff which need to be edited to enable LDAP. . . . See: https://github.com/horilla-opensource/horilla/issues/335#issuecomment-2712573285 Sooo much to see, much to do.

We're using https://www.smslocal.com/ right now. We'd be interested in checking out PlaySMS (https://playsms.org/) and could help test it, especially if it can do what we need it to do compared to our current setup. We know it's open-source and you have to set it up yourself with a gateway, so that's something to keep in mind.

Updated to 13.342 If you find issues, please report here or as github issues.

@robi Correct.

o good to know. nevertheless we should be able to host web VMs on cloudron

There’s actually a deeper issue concerning Open WebUI, beyond just the recent switch to a non-OSI license. The sole maintainer’s demand for contributor license agreements (CLAs), along with how he's communicated and managed these changes, creates genuine uncertainty. Given this scenario, the risk of further license changes becoming problematic for Cloudron users isn't far-fetched. To mitigate this, proactively packaging LibreChat would be strategically smart. It ensures Cloudron users always have immediate access to reliable, fully open-source software, especially if Open WebUI's licensing situation deteriorates further.