@girish Weird blog to be honest. Only two posts with the first one telling us LLMs will hack everything on the internet and the second one ranting about how LLMs didn't find an easy hack but deceived us. I am not skilled enough of doing any testing myself but I am thankful for your overtime hours and acting as fast as you did. If it happens to be not as bad as everyone feared, we can happily move on. As for me, I took it as an urgent reason to finally switch a legacy website. Working under pressure gets things done faster.

@huehner thanks, I checked it: cloudron/php-base:8.5-20261021 indeed ships ghostscript 10.06.0~dfsg-3ubuntu1.1, which is the fixed version for CVE-2026-39919 on resolute (the 20260920 image had ubuntu1). So the PHP rebuilds take care of this one as a side effect. Agreed, the general timing question can wait until the PHP dust has settled.

@andreasdueren yup — been pointing claude at that too — looks like website spammers are gonna be making a right mess for a while

It turns out relying on KVM is equally risky these days. (Though it could be Firecracker related specifically, but there are no public details as of now) https://cybersecuritynews.com/kvm-zero-day-vm-escape

@sponch This reminds me. I gotta move the rest of my domains' DNS from Cloudflare to Bunny. I've been testing BunnyDNS for over a year and experienced ZERO issues. Rock solid service.

Hey, thanks. Unfortunately not -sorry- as this is 100% vibe-coded (by a noob;-) and lots of things are hard coded. But maybe it's an idea for someone who knows what he/she does.

@necrevistonnezr said: Firefox and / or caching issue? Never have a problem on Safari. I almost tagged you to say "not Firefox, same thing in Chrome" My best guess is an ancient unread notification or something Mark all read did the job though (for now at least, but this is the only time it's happened).

@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

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.