Great, thanks!

@james we already have --token (primarily meant for CI automation). It's not saved in the cloudron.json intentionally because long-lived tokens should ideally not get saved somewhere. With login, you get a temporary token that is stored in the cache file. I think maybe your point is that we should use API tokens to login in general? I wouldn't mind removing username/password based login entirely. The current auth mechanism of CLI bypasses all the OIDC security mechanisms . CLI tools like npm already now require auth on browser. I think we will move to this in coming releases. Technically, the CLI was not built for end users, it was only for app development. Not sure how many people this impacts. https://www.npmjs.com/package/cloudron does say ~400 a week....

Hi @James - Many thanks for this. The changes already looks great and promising. May I make a suggestion ? I think, in this case, Freescout approach offers a greater granularity between email notification and in-app notification, with potential for further development based on the communication channel (Mobile if ever, API ? etc..), leaving the end admin users decide what works best for them Here is the screen I am referring to in Freescout. [image: 1753778253533-e6ab2fb5-e080-4b2e-8443-adde0ee3d332-64145699-7f368480-ce22-11e9-9ead-1ac3ef29ba9b-resized.png] If it is not too late in the development of this, maybe it might be worth considering?

I may have posted in the wrong space. But it’s an app request

@jdaviescoates think backups, storage, notifications tab, etc.

@jdaviescoates Yes I know, this was more of a general feature request lol

Hi @marcusquinn, are you still using storj?

Hello @charlesnw Thanks for the clarification.

@girish yep, separate things indeed. That said, it'll be pretty useful for me, that's why I packaged it. About being open, yeah, I don't like that as well, but I'll try to make it work either with basic auth as they suggest (insecure, but better than nothing), or with cloudron's own ProxyAuth, not sure if it would work.

@girish said in VERP on Cloudron: @imc67 this should already work . Support for sending emails with '+' (subaddress) format and sending emails as aliases was added a while ago. If the use case is with Espo, you have to make sure it scans the IMAP mailbox as well . Also: https://forum.espocrm.com/forum/general/58060-verp https://github.com/espocrm/espocrm/issues/1536 https://github.com/espocrm/espocrm/issues/1560 and Thanks!! I’ll give it a try!

WebFinger is not a simple static file (though of course it can be). The URL has to respond based on the acct provided in the query parameter. So, each user needs to have their own links . For the moment, it's best to use something like https://wordpress.org/plugins/webfinger/ . Or if you can code, just write some simple PHP page or static Surfer page to respond . Cloudron's nginx server will query the app.

What is the use case to prevent internal routing? But if you set up an external MX record and add that MX host to your SPF also (so Cloudron will accept incoming), then I think it does what you want?

I am not so sure if every app would need a specific MCP server written for it, because as I see it, the MCP server should expose only the cloudron-specific functionality of any app, not allow with the app itself. What that means specifically: Using Claude Code, Cursor etc. I could prompt "check the production logs of my app to investigate why the hell this doesn't work". Ideally, via MCP, the AI could execute test scripts that have been uploaded before via terminal, or do similar basic things such as go through files of the app. I would be more interested in app-based interactions rather than the whole cloudron itself, but that use case might differ between people.

Connecting... root@16405153-e269-41e3-ab8d-095606d5b07e:/app/data/public/KNEL/FetchApply# gup Already up to date. root@16405153-e269-41e3-ab8d-095606d5b07e:/app/data/public/KNEL/FetchApply# cat /app/data/.bashrc cd /app/data/public/KNEL/FetchApply alias gup='su www-data -c "git pull"' root@16405153-e269-41e3-ab8d-095606d5b07e:/app/data/public/KNEL/FetchApply# Ah this opens up all manner of creature comforts. Excellent! Really appreciate the prompt response @joseph

Mail system is a feature of the platform, so the correct place is to open feature requests here.

fwiw - Cloudron uses timesyncd . Post installation, it doesn't touch the ntp config. Adjusting it to use custom ntp servers should not be a problem. (But this is a good suggestion to have a config on the UI nevertheless.)

@charlesnw Totally +1 for this feature.

@d19dotca You're right. Not sure if there is a Haraka setting per IPv4 interface. My servers seem to have over 200 IPv6 veth's. Uh is that normal?

This is implemented in https://git.cloudron.io/platform/box/-/commit/d7fdfd6d71c403f343f2e37dfc988f2c5a120898 . The app object now contains updateInfo . This has two fields isAutoUpdatable and manualUpdateReason (added in https://git.cloudron.io/platform/box/-/commit/84297ff473d6c0c100d2597e425c7edfe9481f8f)

Inspired by the recent discussion surrounding beszel, I think Scrutiny would be an awesome addition to the app catalog for those that are running there Cloudron on a server with several disks. I already use Scrutiny on my TrueNAS server and it has helped me more readily see the S.M.A.R.T. data and identify drives that are at risk of failure.