Cloudron Forum

My users have come from outlook, so they are used to in-application ability to set an out of office reply that doesn't require leaving the app running. Using sogo web interface is unfamiliar to them, and quite frankly odd. from the inbox page you must pick preferences, mail, vacation, enable autoreply. then fill out the page. you can't leave the page until you save, or undo any changes. you can't go back to general preferences to check the timezone is correct if you ticked the enable box on mail>vacation. you cannot set a different autoreply for internal or external senders. it's very much got the appearance of an after thought.IMO, Ideally a person using an application like thunderbird could set an autoreply, much like the other features of synced calendars & contacts. but there seems to be no mechanism for that to work.

The existing 9.2 release got renamed to Cloudron 10 yayyyyy. Given that it brings Ubuntu 26 support and really lots of new stuff, it's worthy of a major bump.

@robi good catch!

@BrutalBirdie nice work on that colourful overlay!

@robi great find! will give it a try.

Yay !! glad to see it landing on the store ! I'll investigate how best I can transition from my custom package to yours so that I can benefit from futur upgrades

Stubborn dog-with-a-bone that I am, I did more research, and hopefully this can put to bed my diversion of the thread (sorry), and maybe help others with a similar use case / workflow objective to mine : Forgejo (official Cloudron AppStore) provides standard git source code functionality AND it has a built-in container registry functionality so no need to consider changes to the official docker registry app for public pulls forgejo supports private and public repos (which git.cloudron.io does not) forgejo supports public image pulls (like hub.docker.com) but also multiple private containers (hub.docker.com only allows 1) I can uninstall docker registry app and gitea/gitlab apps, multiple used for segregating cloudron community work from closed app dev, using Forgejo organization instead. So the answer for my bandwidth-limited brain of 1 app for (almost) everything seems to be Forgejo (available today, no dev work). However, @girish made valuable comment that hosting container images is a disk/network usage risk. Even for a small dev footprint like mine, this could be critical (let alone Cloudron scale). I need to think & test out, but maybe Forgejo actions can automate container push to hub.docker.com, and do automated cleanup in the instance. So from dev point of view it's a single answer (Forgejo) with CI/CD offloading disk/network risks to hub.docker.com (or whatever).

For anyone curious there is documentation on the Pankow UI library at https://pankow.cloudron.io

Hello @paulfitz Did something change with updates from 04.06.2026 until now in Grist change regarding the enterprise logic or stuff? In the following thread https://forum.cloudron.io/topic/15602/allow-email we noticed that clicking Switch to Full Grist is no longer working for the Cloudron Grist app. Thus, also the enterprise and email notifications are no longer working. Some change must have created this issue from Grist version 1.7.15 or 1.7.16. Since we only recently added the enterprise option again after it was reinstated with install:ee on 19.05.2026 having it fail on us just after two updates again is rather frustrating. EDIT: I have narrowed down that the issue arises when updating Grist from version 1.7.15 to version 1.7.16. In version 1.7.15. In the changelog of grist 1.7.16 is this statement: yarn install in grist-core now builds the full edition by default, via a post-install hook that downloads the ext material from grist-ee. Use yarn run set-community-edition to skip it (the previous behavior) or yarn run set-full-edition to opt in explicitly. The chosen edition is saved to grist-edition, GRIST_EDITION takes precedence, and GRIST_SKIP_EXT_AUTOSETUP skips the hook for contexts where extensions are installed manually (Docker builds, grist-desktop, grist-static) (commit ) According to that, the default should be full but the Cloudron app defaults to community. Using the admin ui and clicking Switch to Full Grist does nothing after a restart. The edition stays community. Even when setting export GRIST_EDITION=full and restarting the app the edition stays community. Even putting the app in recovery mode to allow full read-write, running yarn run set-full-edition: yarn run set-full-edition yarn run v1.22.22 $ echo full > grist-edition && yarn install [1/4] Resolving packages... warning Resolution field "@gristlabs/sqlite3@6.0.1-grist.1" is incompatible with requested version "@gristlabs/sqlite3@^5.1.4-grist.7" success Already up-to-date. $ buildtools/install_edition.sh + ext already at grist-ee (date-2026-06-29-15-21-09); using cached copy warning package.json: No license field warning No license field [1/4] Resolving packages... success Already up-to-date. + Full edition ready (ext/ and ext/node_modules). Done in 1.38s. creates the grist-edition file cat grist-edition full But still, the UI will not use the full edition and stays community. So neither of the documented ways to set the edition nor the web UI is working for the Cloudron app, even when the app is in recovery mode allowing full read-write access.