@bazinga said: So, with cubby - am I able to change a file on my desktop and get it pushed into the cloud where my Android can access the updated file? Yes, indeed, through WebDAV protocol using a normal "file manager" window you type the address of your server using davs:// instead of https:// you'll be prompted for your uname and pw and and once you're connected you're in a folder on your desktop just like any other desktop folder. On a mobile device you can connect through https:// using a web browser and it works pretty well. Whatever the device you use, your files are still at the same place. They're on your server. Whether you access them from your desktop or your mobile. So unless you think you'd be offline for while, in such case you could literally sync some files on your mobile device, there would be no real reason nor a need to sync files from your server into into your mobile device. P.S.: Oh and I also endorse Joplin as a note app it's amazing and so powerful. That one has desktop and a mobile app as well and incredible plugins, you can even connect some AI to chat with your notes and documents and even produce content. Enjoy!

@nebulon sorry to jump in here. CVE-2026-111497 is not just about NodeJS ( that node2shell name isn't great) but potentially anything using the same brotli decoder. i.e. this page https://broccoli2shell.com/ gives an overview of software embedding libbrotli copy (similar as the 'fun' we had recently with the embedded ca-certs) Looking at the 6.0.1 base-image it doesn't contain the libbrotli1 version with the Ubuntu fix yet (1.2.0-3ubuntu0.1) as that came just a few days later only Looking what points to it (apt-rdepends) apache2 (php container, but maybe less critical given the nginx as proxy on the host) curl non-http things (libwoff1, jxl (maybe via ffmpeg) That's not a full or verified list just a first look. Note: I'm also not shouting critical here just writing as above only talked about NodeJS angle. Do you plan to bump the base image again for this? Otherwise are the any plans to do that periodically to catch up to accumulated fixes which don't warrant the overhead of some immediate action?

@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."