Hi, @james! Yeah, I think you got it perfectly. Except I don't think the app-proxy would need to use OIDC instead of proxyAuth. Maybe It could be an option: You either use proxyAuth for authentication-only if your proxied app doesn't have auth capabilities, or you use OIDC and the proxied app would use cloudron as an OIDC provider. I understand there are a few technical hurdles to jump, but I'm thinking they might be feasible. The main one, as you suggested, would be to have the OIDC-related configurations in the manifest dynamically configurable. This feels like it would demand some work, but as I understand it, there's already something along these lines in apps like gitea, where the SSH port is declared in the manifest, but customizable via the web ui. IMO, this would make for a few more nice usecases for app-proxy, like testing apps, or even hosting them elsewhere (like a homelab in my case, or another machine), but accessing them through cloudron and benefiting from its user management. Also, I don't think it would "compete with" or "exploit" cloudron in any way, since these proxied apps would not benefit from cloudron's other great features like automatic updates, backups, external volumes, etc. All the management ease and just general peace of mind that cloudron brings us. Would be a nice use case, though, I think.

@james Yes, same concept. Simple but could prevent accidental data loss.

Yes, the clone follows the user management of the backup. This has to be implemented.

Hello @Andrew Many apps run their own NGINX or APACHE2 inside the app and can be configured on that level or on the application level. For example Nextcloud has the /app/data/php.ini file where you can configure e.g post_max_size and upload_max_filesize to limit that. Same for WordPress. Ideally, each app should have the ability to configure this. From your example, the apps ghost and peertube do not have a php.ini because they run NGINX inside the app. Having the possibility to edit / configure NGINX directives there as well is understandable. I will tag this topic as feature request to track this for the future.

Absolutely. I had the same gripe and reported it to the team. This will be fixed soonish.

@joseph Not sure if I can follow. I understand what @girish said in App proxy questions and proxy/authentication possible improvement suggestions But from Cloudron's POV, there is authentication and authorization But basically adding the option to add optional Authentication in front of any app (presumably through the web server) would be very useful in a lot of cases. This is already a feature in the proxy app but would be good to be a toggle in any app.

Newer OpenSearch versions do not work with Mastodon anymore. This is what I need ES for.

This is fixed with https://git.cloudron.io/platform/box/-/commit/2cb755fe44ad379327186878960255fe0d905f9b

Honestly, I didn't try. I didn't find evidence that this was possible, so I assumed it wasn't. For my needs, I have found a different solution for this now, but maybe this could be helpful to clarify, if it works, then in the docs.

Hello Everyone We have added a guide documentation for Per-App storage limit. If there are questions about this guide, or you have feedback on how to improve it further, please let me know.

This is fixed now for next release.

@ekevu123 The team is keen, you adjust for the different notification types. Date range is still useful, this is just tied to notifications.

Can you give more context what you mean by that? Which API would one use for relaying there, since https://developers.brevo.com docs also refer to regular smtp relay for relaying purposes. Also what would be the benefit there? Like postmark or so, brevo also has an API to send/compose emails but I am not sure how this relates to the relay part here, but maybe I am missing something.

Hello @zack13532 Glad to read that this solution suits you well. Oh, and since that was your first post. Welcome to the Cloudron forum.

@adisonverlice2 IMHO you're confusing apples and pears - that's the polite expression, there are others. It seems you COMPLETELY underestimate or misunderstand the ongoing work needed to maintain and develop Cloudron, and keep it stable. Cloudron is not providing some hardware, and some base software or reselling / redistributing a 3rd party software (eg pfSense). I completely fail to understand why anyone would agree to receive a single payment for the next xx years work they have to do, unless that is 20x the annual price. I repeat : pay a single fee for perpetual licence for a fixed version of Cloudron ? maybe that might work. Want the benefits of a maintained platform with upgrades, forget it. I've had enough of this discussion, which is IMHO is just plain silly.

As far as I understood this, thunderbird maintains an ISP database mainly. So once a domain was manually configured in any thunderbird, subsequent account setups will have the server addresses auto "discovered" from that database.

@girish nice, happy to hear!

@james I'm TERRIBLE at writeups, but I'll summarize it and maybe we can write something better together if you think it's interesting enough: So I have a cloudron machine with a public IP, vanilla setup. I also have a raspberry pi in my home network running a few services, and an external VPS. I use a "hub-and-spoke" wireguard architecture, which is pretty common and straightforward as well. It is set up like so: VPS has a public IP I installed and set up wireguard in it. Let's say it uses interface wg0, and its wg IP address is 10.0.0.1, network 10.0.0.0/24 I had to set a few things to enable packet forwarding on the VPS so it would act as a "router" between my raspberry pi and other devices, but its pretty straightforward stuff I installed and set up wireguard in my raspberry pi, interface wg0, IP address 10.0.0.2; added the VPS added as a peer with its public key, allowed-ips 10.0.0.1/24, and the endpoint is its public IP and the port I had wireguard listen on So now when I turn on wireguard on both VPS and pi, I can ping 10.0.0.1 from the pi, and I can ping 10.0.0.2 from the VPS. This is the simple hub-and-spoke setup, with the VPS acting as the hub (because it has a public IP address) and the raspberry pi and other devices (say my laptop or phone) are the "spokes". So now for the cloudron part: installed wireguard on my cloudron machine and set it up as a peer to the wireguard network, same as I did on the pi. Added the VPS as the only peer, and on the VPS added one more peer which was the cloudron server. Say its IP is 10.0.0.100 I can now ping 10.0.0.1 (vps) and 10.0.0.2 (pi) from the cloudron server, and I can also ping these IPs FROM ANY CLOUDRON APP as well! I had a service running on the raspberry pi on port 8080, so I installed a new app proxy on the cloudron from the app store, and the upstream address was http://10.0.0.2:8080, and it all worked. Now, I COULD get rid of the VPS and use only cloudron, boith as the wireguard "hub" and reverse proxy. That would be great because it's one less machine I have to pay for and maintain (the VPS), and I would benefit from user management and stuff. Cloudron explicitly says it needs to be the sole service installed on the machine, though (which makes sense, not complaining), so I haven't done this yet. Not sure this is a good enough description, but I'm here to answer any questions if needed.