@saivie
App Title and Version: DocuSeal 2.0.2
Package Version: co.docuseal.cloudronapp@1.10.2
No problem sending emails.
The app is configured to send mails using the address below and example.com's Outbound Email settings.
@saivie
App Title and Version: DocuSeal 2.0.2
Package Version: co.docuseal.cloudronapp@1.10.2
No problem sending emails.
The app is configured to send mails using the address below and example.com's Outbound Email settings.
@james No errors in the browser console. Different users & browsers - so no caching issue.
Ok, I checked the behavior again. My results:
The freescout demo server is working as expected. As soon as a user has the right to delete messages, the trash icon is displayed in the list view.
a fresh install of Freescout on Cloudron (without any module), shows exactly my experience.
https://freescout-missing-trashicon.demo.cloudron.io/login
admin: admin@cloudron.local:changeme123
user: agent@example.org:changeme123
For a few days now, I have been missing the trash icon in list views (as a normal user). As soon as I switch to a user with admin rights, the trash icon is there again. I have looked in the permission settings for users and mailboxes, but have not found an option to restore the trash icon (the “bulk delete” option) for normal users.
Trash icon is only displayed for the admin role.
I reported this upstream.
https://github.com/freescout-help-desk/freescout/issues/4819
@fbartels You are right.
Madrid (Spain), October 8-10 2025
https://penpot.app/penpotfest
The next big ai thing may break the current idea of a Cloudron nextcloud app.
AppAPI and External Apps
Previously, Nextcloud only supported applications written in the PHP programming language. In order to support a wider range of use cases, an ecosystem for ExApps (short for “External Apps”) was introduced, allowing for the installation of apps as Docker containers.
Connecting Nextcloud to an LLM is the number 1 wish of NC users. The Cloudron app is far too slow for daily work.
The Nextcloud documentation explains how to speed things up. Do you have any idea how to solve the tasks with the Cloudron app package?
To avoid task processing execution delay, setup at 4 background job workers in the main server (where Nextcloud is installed). The setup process is documented here: https://docs.nextcloud.com/server/latest/admin_manual/ai/overview.html#improve-ai-task-pickup-speed
@SansGuidon umami also works with “higher” traffic, but we had to set the memory limit to 4 GB.
(screenshot shows a time frame of 30 days)
imho one of the most important messages.
Today I spent a few hours updating Nextcloud and some other applications that required manual intervention to the latest versions. At the same time, I was informed that a new Cloudron update had been released. So hours of clicking, with half my attention on progress.
A few minutes ago, I looked into an instance I didn't have time for today and saw
I thought: Shit. What kind of error is this? The app isn't running and isn't updating. It took me a few 10 seconds to remember that this instance uses a lot of “link apps”. That's why there is no “subline”.
Maybe we can introduce something like link, external (I know, the “subline” is more or less information about the app on this instance). Or maybe we can give the tile a different color or something?
io.n8n.cloudronapp@3.82.0
May 08 11:23:51 ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
May 08 11:23:51 at /app/code/node_modules/express-rate-limit/dist/index.cjs:704:5 {
May 08 11:23:51 at /app/code/node_modules/express-rate-limit/dist/index.cjs:724:32
May 08 11:23:51 at Object.keyGenerator (/app/code/node_modules/express-rate-limit/dist/index.cjs:671:20)
May 08 11:23:51 at Object.wrappedValidations.<computed> [as xForwardedForHeader] (/app/code/node_modules/express-rate-limit/dist/index.cjs:398:22)
May 08 11:23:51 at Object.xForwardedForHeader (/app/code/node_modules/express-rate-limit/dist/index.cjs:187:13)
May 08 11:23:51 code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
May 08 11:23:51 help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
May 08 11:23:51 }
It looks like adding export N8N_PROXY_HOPS=1
to env, solved the problem. I did this from https://community.n8n.io/t/x-forwarded-for-header-is-set-but-the-express-trust-proxy-s/51208/7
To give some context: If you run your own mail server, you have the ability to view and analyse log files.
As far as I know, with a SaaS mail server you can't see delivery or bounce messages from sources.
You have no idea if a sender mail server is on a whitelist, even though the server is on a spam list - only because of “backroom conversations” between an inner circle.
I was told by a customer that he had no chance to deliver mails to a large service provider because his sender IP was on a spam filter list. It took almost 10 days to get the IP off the list.
2 weeks later, the customer told us: we are not receiving any mails from the service provider. Because we use the same spam filter lists, the mails were rejected because the service provider's mail server was on the spam filter list.
Because the service provider didn't care, we had to lower our shield to receive emails from them.
It's unfair just because of the flies and shit.
Some are equal some are more equal.
My 2 cents on the discussion about self-hosted email servers: In the early days, everyone had their own mail server because we could and it was the only way to communicate with the world via email. With the advent of capitalism and wider use of the internet, some companies have moved into this “niche”.
I borrow a saying from sport and apply it to open source:
“Created by the poor, stolen by the rich.” -> “Created by open source, stolen by closed source”
Don't be afraid of self-hosting email. We need to take steps to get freedom back.
@joseph That's the plan for the future. Now I'm interested in getting the max number of monitored instances. 62 is way too many. 180 days retention policy for the metrics ditto. Sqlite DB is about 2 GB in size. Purging old data in the database does not work. Let's see.
Since a few days one of our Uptime Kuma instances shows the following error: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?
I found an issue upstream to this error -> https://github.com/louislam/uptime-kuma/issues/2346
The instance has 60+ instances to monitor and the current issues are: no way to delete instances, unresponsive dashboard. The solution is simple: restart the container.
The resources are 50% CPU, 2 GB RAM:
What are your numbers?
Mostly standard VPS at hetzner & co. An instance as a playground on a https://www.zimaboard.com/ In the early days, we used one instance as a backup server. That was bare metal with raid. https://forum.cloudron.io/topic/3508/show-me-your-dashboard?_=1745944465785
We started with a Cloudron instance and used this instance for everything. Mail, web, apps, VPN ... Every time the instance needed a restart, we all crossed our fingers that it would be available again soon.
That was the moment when we decided to split the services into different instances. We currently use about 5 instances that are connected to a central user administration as “IAM” (also a Cloudron instance). Incidentally, it is also better for Cloudron as a company because you pay for more than one license. That's what the (new) plan Business is for. https://www.cloudron.io/pricing.html
With up to 50 users, this works for us. Some of our customers have 400+ users. From this use case we learned that the Cloudron user interface doesn't have nice features for such large numbers of users, mail addresses and group filters. It works, but it's not that nice to use.
New phenomenon: the beard is longer than 6 mm. I wrinkle my upper lip and the whiskers tickle my nostrils. Do you have the same problem?
Solution for the moment: Upper lip beard max. 6mm. We'll see about the rest.