D
@jadudm Agreed. But isn’t that something configurable in the package? Looks like it isn’t a user-facing setting, but I assume this can be taken care of in the code part of the package? I’m not super familiar with packing apps just yet so correct me if I’m wrong.
Probably worth setting the client max body size to 0 for unlimited since there will be all sorts of sizes to an app that’s used for backups. I’m just surprised nobody else has run into this issue, it happens immediately upon backup.
@timconsidine hi Tim,
I tried to use the community app but I get a 413 response code (which suggests the payload is too large). It happens at the very first backup attempt.
Any suggestions? Is there anything I may have missed, or anything you had to do after deploying the app? Did you ever run into the 413?
I’m using tarball and encryption in case that matters at all.
I haven’t used Garage yet but isn’t it just another s3? So it’d basically be a MinIO replacement, right? Do we have any other options for ones with “hardlinks” using rsync? I kind of think the Surfer app would honestly be a great way to use as a backup somehow if it could be used to expose a disk.
I am in a similar position. I currently use iDrive e2 for backups and it’s fine but it does take around 1.5 hours uploading tarballs from my server. I’m looking at possibly deploying a low-budget Kimsufi server in the same OVH data centre and just mounting that disk as SSHFS to Cloudron on my primary server, haven’t tried it out yet. If I go this way I will likely still keep iDrive as a second backup destination and just run it a little less frequently and with lower retention to save on costs a little bit there.
I’m wondering about MinIO alternatives as I tried MinIO on a second Cloudron install but it seemed to take even longer than uploading to iDrive e2 somehow (I expected it’d be quicker not slower). It seemed the project is dead too but then it also looks like there’s an active fork that maybe the Cloudron @staff can look into using instead. Brings back many of the lost MinIO features by the sounds of it too.
Thinking of other avenues to keep backups more “local” or as close to local as possible for rapid quick backups, and then completely offsite as a second backup plan too.
I have around 65 GB compressed to back up, around 125 GB uncompressed, I believe.
@girish , is this perhaps something we can consider adding in one of the next updates? This would be greatly beneficial to be able to specify the IP address for outbound traffic in Cloudron (at least for the mail container but maybe all containers in one setting might be better for some people, not too sure what the best approach is).
I found a couple of other related topics so it seems like there is a need for this. I think my solution should still work but likely just needs to be adapted by Cloudron to be more built-in with a GUI to set the outbound traffic IP (or maybe just have it default to the IP set in the Network page by default as I suspect the DNS record IP would be the same IP outbound traffic would be desired).
Other related topics I found:
In Cloudron 9.1.5 on the Event Log page, there is an issue with the Time column overlapping with the Source column, per the screenshot below:
I thought this was fixed previously or reported previously but I couldn't seem to find this report yet (forgive me if this is a duplicate).
In the browser, I did something like this to fix it, hopefully this can be included in the next patch:
Instead of <th data-v-cbe2d74a="" style="width: 160px;">Time</th>, I changed the width to 190px like this: <th data-v-cbe2d74a="" style="width: 190px;">Time</th> which seemed to resolve it per the screenshot below:
There's probably some different values that might work better, but that should at least resolve the issue where they overlap.
This was observed using Safari on macOS (26.4) by the way on a widescreen monitor, in case that helps too. 
Personally, I also liked the view if I changed the following from 15% to 10% (<th data-v-cbe2d74a="" style="width: 10%;">Source</th>) as it brought in the Details column so more details could be seen in a single line (not sure if this will work on mobile or tablets though). Just seemed like there was a ton of white space between Source and Description columns to me. 
Maybe a minor improvement that can be made at the same time.
Hi all,
I've run into what appears to be a bug in the WordPress app where editing AVIF images results in a 0 KB file being written — essentially a blank/corrupt output. Uploading AVIF files works fine, and cropping WebP images works as expected, but any edit operation on an AVIF file fails silently with no error shown to the user other than the display showing a missing image.
Steps to Reproduce
This also affects setting a site favicon when the source file is AVIF (since it usually requires an image crop).
Environment
Screenshot included at bottom of post for whole Media Handling section of WordPress Site Health.
Suspected Cause
While ImageMagick 6.9 lists AVIF in its supported formats, reliable AVIF encode/write support appears to have been incomplete in the IM6 branch — the failure seems to occur at the re-encode step after editing. GD 2.3.3 is present but was compiled without libavif/libaom support, so there's no fallback path available either.
It's worth noting that IM6 is in maintenance mode — the version currently in the WordPress app (6.9.12-98, from 2023) isn't even the latest IM6 release, which is 6.9.13-38 as of January 19th (per https://imagemagick.org/archive/releases/). Whether the issue lies specifically in the ImageMagick version, the PHP Imagick extension, or the underlying libavif/libaom libraries not being compiled in, I'm not certain — happy to dig into this further if the team has ideas.
Possible Fix
Updating to ImageMagick 7.1.x in the WordPress app Docker image may resolve this. I appreciate IM7 isn't in the standard Ubuntu apt repos and would likely require compiling from source — so this isn't a trivial ask. That said, IM6 is effectively in legacy mode at this point, and IM7 brings broader improvements beyond AVIF support. As AVIF becomes increasingly common on the web, this is likely to affect more WordPress users on Cloudron over time.
If there's a different suspected cause or a simpler fix (aside from not using AVIF, lol), I'd be very open to exploring that too. Happy to provide any additional diagnostics if anything else is needed.
Thanks for looking into this!
in case it helps, here is an image of what is displayed in WordPress Media Library after cropping an AVIF file in it:

Media Handling screenshot from Site Health:
@imc67 I checked just a bit ago but didn’t actually see any update to the Developer one yet. Maybe I checked too early. Hopefully we see it soon so we can update the plugin.
Looks like just a short bit ago version 3.11.3 is out now.
https://github.com/oidc-wp/openid-connect-generic/issues/633#issuecomment-3894814402
I've released 3.11.3 which provides a setting for the issuer url. This seems like the the most reliable way to ensure each site can adjust depending on their IDP.
@ccfu I tried in double-quotes but there was no difference, still throws the same error. Single-quotes too.
I noticed that when I try to set an email display name for a Cloudron app like WordPress that it won't allow values with commas in it. I'm trying to set the legal business name, but for some reason this is not working. The error I see in the user interface is mailbox display name is not valid. Interesting it accepts the ampersand (&), but not the comma (,) characters.
Is this intended behaviour though? It seems like a defect to me because I can't imagine why commas are not valid "From Display Name" characters, but wanted to double-check. To my knowledge, commas are allowed in an email "From Name".
I think Cloudron needs this database software for a few apps too that are in the Wishlist, such as Rybbit, Plausible, Dub, and more.
@marcusquinn said in Sharing custom SpamAssassin Rules:
Nice, so which would you recommend?
For the Cloudron DNSBL list? I personally am using Spamhaus and Abusix's Exploit list to completely reject only the most obvious of spam, leaving the rest to be filtered via SpamAssassin to the inbox or junk folder.
zen.spamhaus.org
{API_KEY}.exploit.mail.abusix.zone
I stumbled across this page this evening: https://docs.umami.is/docs/enable-redis
It seems like Umami can take advantage of Redis for some performance improvements. Just wondering if maybe this should or could be added to the Umami package in Cloudron.
@imc67 said in Sharing custom SpamAssassin Rules:
@msbt said in Sharing custom SpamAssassin Rules:
Thanks a bunch for the list @d19dotca! Quick question about the rest of the setup though: Do you still have entries in the Email ACL DNSBL Zones or is that empty because everything is handled in the custom rules? Like those:
zen.spamhaus.org bl.mailspike.net noptr.spamrats.com dnsbl.sorbs.netOr is that empty on your side?
I think this is still a relevant question, @d19dotca your spam-rules are amazing, however you are "calling" ACL DSNBL's that are not default in a Cloudron install (https://docs.cloudron.io/email/#dnsbl) so I guess that they are not working until you add them?
I asked ChatGPT to analyse your latest rules and it advised to add the below ones to the DNSLBL Zones ACL (https://my.domain.com/#/email-settings). Is that in your opinion correct to make them all work?
zen.spamhaus.org bl.mailspike.net noptr.spamrats.com all.spamrats.com backscatter.spameatingmonkey.net bl.spameatingmonkey.net netbl.spameatingmonkey.net
So just to clarify… if you add those to the DNSBL list in Cloudron mail settings, it will completely reject mail that has a hit on any of those services. That mail setting in Cloudron is used by Dovecot/Haraka, not SpamAssassin. The reason you don’t want all those DNSBLs there is because not all of them are super accurate (some are too aggressive), which is why they’re in the SpamAssassin rules instead.
Basically the DNSBL list for Cloudron should only be if you want anything that has a hit to be outright rejected and never arrive in your mailbox (not even the junk folder). I prefer to keep that to just Abusix and SpamHaus myself because they have proven to be very accurate in the sense that they return no false positives, so they’re “safe” in rejecting only the most obvious of spam.
Then everything else that passes through that part will simply be scanned by SpamAssassin against the other DNSBLs in the custom rules and are therefore not rejected but just categorized as either spam or ham. It’s safer that way.
But also totally up to you. If you trust the other DNSBLs, then certainly feel free to add them to the Cloudron DNSBL list, but just know that doing so will most likely result in rejected/dropped messages that you’ll never know about until you look at the mail sever logs.
Ultimately… the DNSBLs in the custom SpamAssassin rule set doesn’t really have anything to do with the DNSBL setting used in Cloudron, as they are different levels of filtering and unrelated to each other.
Hopefully that makes sense. I’m just waking up while writing this so let me know if I can clarify further as I may not be explaining myself perfectly, lol.
Update: I think the theory on the plugin name change was the right area.
In the Cloudron SSO plugin, I changed this line (line 27 in cloudron-sso.php):
* Requires Plugins: openid-connect-generic
to be this instead...
* Requires Plugins: daggerhart-openid-connect-generic
Then I was able to enable the Cloudron SSO plugin and this resolved the issue, I was able to login again via SSO.
Tagging @girish for visibility.