AppsMonitor updated to 0.0.20 in order to make it work on Cluodron 10.0.5. But this means the public page is not working (maybe it’s not even a feature which many want). Public page functionality will be restored when Cloudron 10.1.0 is released.

Thank you both @andreasdueren and @james for your great work and dedication!

@creative567145 thanks for bringing this to my attention, this was a problem on the gitlab level which is now resolved.

@james We have created a feature request for this: https://forum.cloudron.io/topic/16011/full-backup-carry-on-past-a-failing-app-then-keep-the-backup-marked-as-partial

@robi and others : enhanced disk usage, free space reporting and velocity check with alerts are now in AppsMonitor : https://forum.cloudron.io/post/129932

Security update: 1.0.3 (OpenBao 2.6.3). Please update. OpenBao published nine advisories on 23 September, fixed in 2.6.3 and 2.7.0. This package ships the 2.6.3 patch release, so there are no new features, only the fixes. The most serious is a CRITICAL remote code execution in which a raft snapshot restore replaces the plugin catalog (GHSA-j6wc-jpvg-xfxq). This package uses raft storage, so it applies here, although it needs a highly privileged token to exploit. Also fixed are three HIGH issues: an ACL bypass via non-canonical URLs, a cross-namespace policy cache flaw, and unvalidated SANs through PKI ACME. There are also an open redirect in the OIDC provider UI and four low-severity issues. The update also moves the package to Cloudron base 5.1.0. Before publishing, it was tested as an update over real secrets, including a restore into an empty store and an OIDC sign-in, and it's already running in production. Some scanners will still list a few old OpenBao CVEs against the bao binary. Those are false positives: the release binary reports its Go module version as v0.0.0-…. Upstream is fixing that in 2.7 (openbao/openbao#3184). We love Bao and will do our best to keep this package well maintained.

Update: 0.10.0 (Langfuse 4.43.0) is out. It moves to Cloudron base 5.1.0 and applies two Postgres migrations and one small Click House migration automatically on first start. Something to know: a vulnerability scanner will report four CRITICAL findings, all in the bundled MinIO and its mc client. No fixed MinIO build exists yet, and the affected parts (AMQP notifications, a gRPC server) aren't used by this packag e. Replacing MinIO is next on the list. We expect to move to a slower cadence for Langfuse updates or security-only, because upstream releases almost daily.

Big thanks to the brilliant @timconsidine for his interest and vigilance and for immediately notifying we were initially on an older base image of cloudron. This crawl4ai is now on Cloudron 5.1 and we will be moving the rest of our fleet to the new base when they need updates, too.

@LoudLemur I can log in now with Android mobile app but sync failed: https://github.com/OrcVole/wger-cloudron/issues/1 Resolved Edit: removed from battery optimization and waited some minutes. First sync finally worked. Thanks

@robi ooops, thanks for the nudge.

@joseph here we go ! https://ca.cloudron.io/app/documize-conversion

@rstockm thank you Hoping to make it part of “work anywhere” dev cycle. I find the UI a little frustrating in places, but it’s just a case of getting used to it.

@jdaviescoates I've refined the output parameters to enforce stronger positive parameters. And replaced the graphic.

vLLM package 0.3.0 (upstream vLLM 0.29.0) check your model before this one updates This release is labelled a minor rather than a patch on purpose: vLLM 0.29 removes ten model architectures and makes Model Runner V2 the default engine. Most installs are unaffected, the package's default model (Qwen/Qwen3-0.6B) and mainstream families like Llama, Qwen, Mistral, DeepSeek and Gemma all continue to work. But if your LLM_MODEL points at one of the removed architectures, the app will fail to start rather than degrade gracefully: Arctic, Chameleon, Cheers, Fairseq2Llama, FireRedLID, GritLM, HCXVision, MPT, the RWForCausalLM/StableLMEpochForCausalLM aliases, or PrithviGeoSpatialMAE. The same applies if you pass the now-removed VLLM_TEST_FORCE_FP8_MARLIN or VLLM_ROCM_USE_AITER_FP4_ASM_GEMM through LLM_EXTRA_ARGS, or rely on the PyAV video decoder backend (use OpenCV or Torchcodec instead). If you have auto-updates enabled, check the LLM_MODEL value in your app's Environment section now. If it names one of the above, switch to a supported model before the update reaches you. If it has already updated and the app will not start, Cloudron takes a backup immediately before every update, so restoring that backup returns you to the previous version while you pick a replacement model.

That is fixed now, needed an openid integration fix. Thanks for reporting!