Cloudron Forum

@fbartels love the ingenuity, but I don't quite like the hijack to an external site. The App Store is still the primary vector to all app installations. Custom Apps is just an another option, as it is now, without leaving the interface. Just another Cloudron modal that lists the community apps. Works across desktop and mobile.

Quick update: Hetzner offered to replace the server but keep my drives (new motherboard, CPU, RAM). The replacement might have a different CPU (e.g. AMD instead of Intel) or a different board. Could this cause any issues with Cloudron? I'm thinking the network interface name might change (enp5s0 → something else). Is there anything else I should watch out for?

Attention: I have made a few tweaks to my release pipeline and as a result of that the url of the CloudronVersions.json has changed. The shop listing has the updated url, but I don´t think there is an automated upgrade so the app needs to be removed and reinstalled.

Hello @loudlemur Like this? [image: 1784110856247-b7af5b0f-e1a4-4ad5-9464-15c3b630d99a-image-resized.jpeg] This does already exist. In the Dashboard under Server you can select what apps to display in the graphs.

Hi Forum, I can't seem to get Seaweed to use my available disk space or more than one bucket. Has anyone had the same issue? Background: I have been looking to replace my Minio S3 service with either garage SeaweedFS or RustFS and choose Seaweed. My main use case is to use S3 for tarball backups and I have a server with 14TB of space to use for this. Minio was good for this, however it no longer has a future in the OS community. SeeweedFS works well and is good to use, plus it is stable. RustFS also works well, has fewer features (that I probably don't use) but is not stable yet. Issues: After installing Seaweed it works fine as installed, but it appears to be set to a maximum useable limit of 8Gb and also I get errors if I try to use any second bucket at all - no free volumes. I see in file manager and the Seaweed dash that I already have 8 volumes. The my first Cloudron Server backup saves fine, but fail after 8 Gb, my second Cloudron server fails if I try to set it to a different bucket with the no free volumes error in the logs. Using weed volume.list I can see the volume size limit is set to 1024 MB (also visible in the dashboard) and the max number of volumes is set to 8. I have not been able to increase these and it appears that the Cloudron App has set some parameters in the start script which I haven't found a way of overriding in env.sh. I suspect I need to override the defaults to expand the usable space, for example I could do 430 volumes × 30,000 MB = 12,900,000 MB => 12,900,000 MB = 12.30 TB of raw data storage, leaving headroom for indexes etc, but I can't seem to override these in the Cloudron App: volumeSizeLimitMB - I understand there is a build limit to 30Gb (30000) to do with 4 bit sizes maxVolumeCounts - either to 0 for auto or a sufficiently large number that x the Size uses the available disk space I have tried numerous options in env.sh and none change the setting, even if I remove the existing files, volumes and collections. Options include: export WEED_VOLUME_ARGS="-max=126" or export WEED_MASTER_ARGS="-volumeSizeLimitMB=30000 -maxVolumeCounts=hdd:126" I can achieve this with a custom start script called from env.sh (which shows it is being run), but of course this breaks everything Cloudron. Is there a way to do this, or am I missing something? If not, can you expose the variables so that we can achieve using the available disk space and multiple buckets (collections)? Thanks in advance!!!

Thanks for your patience, this was a third, different layer of the same upstream release, and should be fixed in 2.0.6. What happened: OpenClaw v2026.7.x introduced a strict startup check. After an update, the gateway runs state migrations and refuses to start if any migration finishes with a warning. Your install has older Memory Core state files (memory/.dreams/*.json) whose contents had already been migrated to the new SQLite store, so the migration skipped them with a "left legacy source in place" warning. And that recurring warning was treated as fatal on every restart, hence the permanent "Not responding". 2.0.6 now attempts the package self-heal on startup: it runs upstream's documented remedy (openclaw doctor --fix) automatically before starting the gateway, and then archives the already-migrated legacy state files to /app/data/legacy-state-archive/<timestamp>/. Please update to 2.0.6, it should then come up healthy with no manual steps. If it still misbehaves, post fresh logs and I'll take another look.

Looks like Omniroute is the better choice and since @timconsidine already packaged it, use that instead. It's in the Community App store already.

An empty changelog breaks updating a community app, I believe. The update is never shown, and clicking on the button to update it manually makes it load indefinitely without any log entry. Is there a way to get some sort of feedback for this, so that it doesn't come down to guessing? What would be even better: some sort of API that I can use during deployment to automatically validate the file and warn me of any issues. But making the above more transparent would be already helpful!

Our recommendation is to use a data-only e-sim (eg silent.link) and ditch the phone number. If you need SMS for 2FA, just use a web provider such as crypton.sh fyi, for calendar you'll need a caldav bridge, davX is available on Zap Store On Zap Store you can also see what apps others are recommending / installing (and zap the devs directly)