@nostrdev thank you so much for this detailed analysis. Very valuable and helpful. Like a wide-eyed newbie, I've previously relied on containerisation as my comfort blanket, and this rabbit-hole has shaken me awake. Vulnerabilities in a packaged Hermes (or Dify or AgentZero or whatever) are a real risk. necessitate the consideration of perhaps running a separate cloudron instance for non-business critical services. This is also the direction my AI-driven research led me. Different and not itself a solution, more of a workaround or security-methodology in the absence of any Cloudron-supported changes/practices. Basically off-load risky activities to controlled environment : agent brain/control-plane (Hermes, whatever) CAN be on a standard Cloudron BUT configured or locked down to not run agent tasks itself on Cloudron sub-tasks created by "brain" on a separate box (non-Cloudron, not needed to be), possibly small single-node Kubernetes, which fires up disposable tasks in Kata container (Firecracker or QEMU-vm), genuinely isolated VM, locked down, controlled ingress (instructions & task input) and egress (LLM calls, resources), output returned to brain, auditable activity with canaries. I'm tempted to do a proof-of-concept on this, purely out of interest. But I'm conscious it doesn't solve what most people actually want : single app on their single Cloudron box which does wonderful magical things. So why spend any time doing PoC. The 2nd box seems to be the answer, but also the blocker. No-one really wants cost/admin of a 2nd box, unless they re-imagine it as actually a cheap approach to good security. An alternative maybe is to use Fly.io ("sprites" or "machines", not sure) : delivers 2nd box functionality but it's an external service (so extra cost, dependency) and maybe contravenes an "entirely selfhosted" principle. But we regularly use cost-bearing external services (LLMs themselves) so why not. Personally I find my AI's suggested 2nd box suggestion practical but not very helpful, and rather primitive or unsophisticated in the amazing new world we live in. "Blue-sky thinking" might include : best : platform changes for more container defences (probably unlikely as Cloudron team are always inundated, e.g. @robi long-standing sysbox discussion) compromise : "Defender" module, maybe installable app but probably platform-based, which vets all intra-container activity (I have absolutely no idea whether or how this could be done) fall-back : agreed framework for community app packagers which enforces security-sensitive implementation of Hermes-type apps, packaged apps to declare, document, and verify compliance.

Thank you, that gave me something to work through!

I don't have a good solution but we should probably bump up our minimum requirements to 30GB probably... Linux/Ubuntu/Docker images all add up I guess.

@girish I just wanted to relay that this workaround works.

@joseph said: This might be an excellent feature for the new webmail app, no? Just read about it, I will post it as a feature request there, thanks!

@joseph wouldn't it just need to make an http call at the moment the settings load?

@necrevistonnezr my own approach at present is to mostly not use Community Apps yet. If/ when I do so, I like to check e.g. When the user reg'd on this forum (as a proxy of how long they've been using Cloudron) The users "reputation" score on the forum If the user has an "App Dev" or other (e.g. Partner, Translator) badge on the forum How often the Community App gets updated (which I'd then compare to how often the upstream up gets updated) Ideally, I'd like http://ca.cloudron.io/ to help surface this info in one place to inform my decision-making.

Yeah, my last email got delivered as they replied back. I'll check the status for each email to see if I can spot any difference. If not, I'm positive it's on their end and that's all that I care about. I tried troubleshooting things with the client and I get vague responses back like they're a freaking politician and I'm an investigative reporter trying to expose them "delivery-status": { "attempt-no": 1, "certificate-verified": true, "code": 250, "first-delivery-attempt-seconds": 3.223, "message": "ok dirdel", "mx-host": "mta7.am0.yahoodns.net", "mx-host-ip": "67.195.228.110", "session-seconds": 1.087, "tls": true "event": "delivered",

you can also run the management /dashboard component: https://ca.cloudron.io/app/wazuh

cc @nebulon @girish

We will have to implement this in the manifest in a future release. A workaround is a docker systemd drop in with --default-shm-size=512m in it .

Running an alternate mail server on Cloudron is unlikely. Automated provisioning of email setup of apps is part of the product (from v1 of Cloudron) and this would break if we supported other mail servers.

If I use this MCP, can I update several apps in just one-command?

@fbartels I think the idea of moving more towards security is good. There is still much more to discover and implement there.

@LoudLemur the addition of community apps to the platform as a workflow is little short of seismic for Cloudron, massively reducing pressure on the team by avoiding pressure from the Wishlist of “please package me” requests. It works so well there is little incentive to adopt a community apps into the official store. I kinda doubt any community apps will be adopted unless they have some strategic significance. Just my guess. We shall see.

TL/DR The % score on CPU usage in the graph is for CPU Cores, eg 500% means 5 (of your many eg 12 cores) are working at maximum capacity. It doesn't mean that your entire 12 core machine is at maximum. If you have 12 cores, you might see the y-axis reaching 1200% and be wondering how on earth anybody might end up there. It would be because then all of your (in this case) 12 cores would be maxed. We hope team cloudron could provide this additional context in the panel. The cron heartbeat to catch brief reclamation spikes is a good trick I had not seen before. Worth adding a companion trap for anyone who arrives here from a search, because it produces the same symptom, "my box looks busy and I do not know why", and it is worth ruling out before you open a ticket with your provider. Two of the numbers on hand are easy to read as CPU usage when neither of them is. I went looking at one of my own boxes today, convinced it was still labouring after a genuine runaway had been dealt with. Twelve cores, and the figures were: load average: 15.78, steady across 1, 5 and 15 minutes CPU: 80 per cent idle, iowait 0 per cent, steal 0 per cent memory pressure, from /proc/pressure/memory: 0.00 one app's graph in the dashboard, earlier in the day: around 700 per cent, which is seven of the twelve cores The box was completely fine. Nothing needed doing. The load average is not a CPU utilisation figure. On Linux it counts processes that are runnable or blocked in uninterruptible sleep, so a machine running many containers shows a persistently elevated load while the CPU sits mostly idle. I had 92 running containers at the time. Ninety-two containers' worth of health checks, schedulers and database background threads constantly waking, doing a little work, and sleeping again will hold the load average in the teens on a box that is doing almost nothing. vmstat 5 2 and the idle column is the number that actually answers "is my CPU busy". The per-app CPU graph is in core units, not machine units. The thing to hold on to is this: 500 per cent does not mean five times your machine. It means 100 per cent of each of five cores, out of the twelve you have. So it is five twelfths of the box, not five boxes. It follows the Docker convention where 100 per cent means one core, the same as docker stats and the same as top for a multithreaded process, so on a twelve core box the ceiling is 1200 per cent. An app sitting at 700 per cent is saturating seven cores and leaving you five. That is genuinely useful information and it is the right unit for comparing apps against each other. It is simply very easy, the first time you meet it, to read a number above 100 per cent as "more than my whole machine" and start looking for a fire. Both of those are correct and conventional. The problem is that neither is interpretable on its own, and the question you actually have when you go looking is "is my machine in trouble", which neither answers. So, a small request to the Cloudron team, in increasing order of effort. Put the core count on the per-app CPU graph's axis. Labelling the maximum as 1200% (12 cores), or drawing a ceiling line, would remove the ambiguity completely, and it is about as small a change as a graph can take. Offer cores as an alternative unit. "5.0 of 12 cores" is unambiguous in a way that "500%" will never be, however conventional the percentage is. On the system level view rather than the per-app one, show machine-normalised CPU alongside the load average, and say somewhere nearby that the load average is not a utilisation figure. The per-app graphs are fine for comparing apps and cannot answer the question about the machine, and that gap is where people end up guessing. None of this is a bug, and I am not suggesting the underlying numbers are wrong. It is that the presentation asks the reader to bring context that is not on the screen, and in a thread like this one you can watch that cost people real time before they get as far as suspecting their hypervisor.

Awweesoomeee!