@Teiluj any plans to implement this in cloudron - as there is DeSec already as a domain provider. @girish @James

@firmansi https://git.cloudron.io/platform/box/-/blob/master/src/cron.js?ref_type=heads#L128 just change that line to whatever interval you want as a workaround . the change won't survive cloudron updates but a quick fix for you to get the server back up.

@joseph thanks, i'm aware + still exploring a bit how to work / document workflows for ourselves. But the local build has also a couple of subtle behavior changes RUN --mount=type=bind in Dockerfile doesn't work (requires BuildKit) in local build (but working with local docker + Container registry) (but can easily be worked around using ADD) backup restore works quite differently as there's no 'image' to just install but instead source.tar.gz which get's rebuild on moment of restore re-building later can fail i.e. i some hard coded external package version is no longer available on restore time. I guess that's also reason for this URL change here in one of your apps https://git.cloudron.io/packages/guacamole-app/-/commit/ad3e34af5acb3901b5f555ba61e227efd6b4e246#line_6651ddff6_16 (as i hit that myself dlcdn only carries latest packages, while archive has all older ones also (but seems much slower)) None of those are big problems for some local work/testing just listing a bit that it's not totally the same. Anyhow it's just an idea / feature request (the 'exclude this app' was already my attempt to try to sell it easier (avoiding to impact sales for normal usage))

@girish Hi, i was looking at the umami Dockerfile and i think we could save another 200MB here on top. The pnpm install is not adding --prod here https://git.cloudron.io/packages/umami-app/-/blob/master/Dockerfile?ref_type=heads#L23 So it's also adding all the devDependencies to node_modules (i.e. vitest, etc) Skipping those slims the node_modules slightly (200MB) There's one small problem though the "pnpm run build:geo" part fails then as it uses the tar module which is only in devDependencies. Adding tar manually there as a workaround get's it to work. I did a quick "cloudron builder build" and also cloudron install (as quite a bit of the build process is on start time) and with just that tar workaround it went through and can login to the app. I didn't report that tar bug upstream or did any more testing (as i don't actually use umami). Was just curious myself if we could same some more space here.

@timconsidine said: @necrevistonnezr what cloudron version are you on ? 9.2.0 ? or 10.0.5 ? 10.0.5

@ruihildt said: Relying on application level isolation is asking for trouble. Letting a foreign agent lose on a production system is nothing short of insane, actually. People are completely losing their grip on reality with their chatbot religion and I really hope that the Cloudron devs are smart enough not to give into it. I'm already at a point where I'm not reading feature requests anymore due to the constant AI this, AI that nonsense, brought up by what I can only describe as mental midgets.

Good point, I hadn't thought about the layer sharing. I measured it: an apt-get upgrade on top of cloudron/base:5.1.0 today is 136 packages and a 677 MB extra layer per image, so with 30 apps that really adds up. On top of 6.0.0 (5 days old) it's only 16 packages and 28 MB. So for my 7 own apps the per-app upgrade is fine, but for the whole catalog it clearly belongs in the base rather than in every app. If the dated bases (like node-base:24-20260920) get refreshed regularly and apps pick up the latest one when they're rebuilt, the sharing stays intact and the backlog never grows big. The numbers above also show that the older the base gets, the bigger both the security backlog and the upgrade layer become.

VPS (shared resource) is always a risk, but I only ever had one problem where claimed specs were not really available runtime (SSDNODES). Netcup is decent so you should get what you pay for. But if your Cloudron is "production" (meaning you rely on it for services), I would go for something more dedicated resource. My first destination is Hetzner Auctions. Interestingly their auctions are cheaper than their shared-resource VPS currently. They're pinched on RAM etc costs, but auction is still cheaper than VPS. My current Hetzner production cloudron is cheaper (60 euro) with much better specs than their cheapest dedicated auction (75 euro). But I think it's an industry thing, rather than a Hetzner thing.

@james said: Not sure if helpful, Brilliant Brutal Birdie and thanks, that helps a lot!

I think you are referring to https://docs.cloudron.io/installation/home-server correct? What is the issue you are facing? Cloudron will get certificates via DNS automation, it doesn't require port 443 to get certs in that case. See https://docs.cloudron.io/installation/home-server#dns-provider

A YT guy always ends his prompts with ".., answer in short."

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?