What's coming in 9.1

[girish]

@msbt yes, we have started the roll-out.

[sponch]

went smooth - except SFTP+
2026-03-07T10:42:32.173 ERR error initializing data provider: failed to connect to user=usercdd5780385b84f3482b83f6a184b36c9 database=dbcdd5780385b84f3482b83f6a184b36c9: hostname resolving error: lookup postgresql on 127.0.0.53:53: read udp 127.0.0.1:43967->127.0.0.53:53: read: connection refused
Mar 07 11:42:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.18.18:8080
Mar 07 11:42:42 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.18.18:8080

several restarts.

[timconsidine]

Cloudron v9.1.3 is available
This update is a pre-release and not considered stable yet. Please update at your own risk.

Which version is being rolled out ?

[girish]

@timconsidine 9.1.3 is being rolled out . The upgrade path will be straight from 9.0.17 to 9.1.3

[msbt]

@girish well...

[timconsidine]

@msbt 9.12 ?

[msbt]

@timconsidine exactly

[nebulon]

Oh those cloudrons seem to have fetched the update info previously and didn't catch the jump directly to 9.1.3. Going first via 9.1.2 is harmless though.

[girish]

I think in @msbt 's case the Cloudron already updated to 9.1.x unexpectedly (from a previous post). So, this is expected. For those on 9.1.x already, it is correct to update 9.1.0 -> 9.1.1 -> 9.1.2 -> 9.1.3 . Basically, we can't and don't test all the possible code paths when we make new releases. 9.0.17 -> 9.1.3 was explicitly tested since most people are on 9.0.17.

[jdaviescoates]

@girish said:

I think in @msbt 's case the Cloudron already updated to 9.1.x unexpectedly (from a previous post).

But did you ever get to the bottom of why that happened?

[jdaviescoates]

@girish said:

@timconsidine 9.1.3 is being rolled out . The upgrade path will be straight from 9.0.17 to 9.1.3

I still get the "This update is a pre-release and not considered stable yet. Please update at your own risk." warning:

[girish]

@jdaviescoates that's the correct behavior. it's being rolled out in phases. are you expecting something else?

the alternate message here would be "This update is being rolled out." but given our small team size, we want something deterring people from all updating at once.

[murgero]

@girish

This version is currently being rolled out gradually during testing.
We recommend waiting for the automatic update instead of installing it manually.

?

[james]

Hello @murgero

Currently, we use the message This update is a pre-release and not considered stable yet. Please update at your own risk. in two cases.

Case 1:
What the message states exactly.
The update is pre-release and not considered stable yet.

Case 2:
We also use the same message when we are rolling out the finished update to lower the load so not all systems automatically update at the same time.
DDoS protection against ourselves and to catch regressions that we might have missed early with fewer instances effected.
In Case 2, the automatic update would still trigger at some point when it is your systems turn to update.

When we post the announcement in the Forum that e.g.: 9.1 is released, case 2 is in effect, but the message is still the same.

I understand the confusion here, and we will improve the message in this case to reflect what is actually happening.
We simply did not get to it, yet.
Apologies for the confusion, we will improve this in the future!

[hakunamatata]

I upgraded from 9.0.17 to 9.1.3 yesterday and everything went smooth as butter! Thanks to the Cloudron team for the awesome work!

[murgero]

@james I understand, I was suggesting a change for situations like Case 2 - a little more transparent but still a short message as to not confuse users/admins.

[girish]

9.1.5 is now in unstable. It fixes many minor issues and one major issue related to passkeys in 9.1.3.

[9.1.5]

• services: lazy start services / on demand services
• restore: fix restore of trusted ips and blocklist
• dashboard: wait for dashboard reload when version has changed
• graphite: fix aggregation of block/network read/write
• Workaround chrome quirks on file drop handling
• notifications: add empty text, progress bar and inifinite scroll
• rsync: throttle log messages during download
• backup logs: make them much terse and concise
• oidc: implement Device Authorization Grant
• operator: fix viewing of backup progress and logs
• notification: automatic app update failure notification
• backup sites: identify conflicting site locations
• update: add policy to update apps and platform separately
• passkey: fix issue where passkeys were lost on restart
• passkey: implement passwordless login
• oidcserver: fix jwks_rsaonly response

[paradoxbound]

Not sure if this is the place to ask but when is 9.2 due for release? I am waiting for a fix to Full-text search, I was told it should go into 9.2?

[jdaviescoates]

@paradoxbound said:

I am waiting for a fix to Full-text search, I was told it should go into 9.2?

You mean for email accounts with loads of mail? (that's what I remember reading about somewhere)

[paradoxbound]

@jdaviescoates Yes I did some digging and found the root cause at least for me. My users have some huge mailboxes. I am just waiting for the fix so I can enable the feature again.

Issue:
The mail container's Solr instance is repeatedly crashing with OOM
errors when attempting to index a large mailbox (hundreds of thousands
of emails). The JVM is hardcoded to 512MB heap and crashes during XML
parsing with OutOfMemoryError: Java heap space.
Evidence:

Continuous SIGABRT crashes every 1-2 seconds visible in supervisord logs
JVM crash dumps showing OOM during XMLLoader.readDoc
I can supply crash logs from /run/solr/logs/ on request

Root Cause:
The 512MB heap limit is insufficient for large mailboxes. Solr's
bin/solr script supports SOLR_HEAP and SOLR_JAVA_MEM environment
variables, but there's no way to configure this in Cloudron.
Request:
Please add configuration support for SOLR_HEAP (either via UI setting or
/app/data/solr/config.ini) so it can be increased to 2048m for
production mailboxes.