The CLI was just meant for app packaging . It's not a priority for us but happy to take in PRs if people want to build on existing CLI. cloudron domains list etc. Repo is at git.cloudron.io/platform/cloudron-cli

I'm in the same boat. I pass the cost over to the client. However, I run Cloudron on a Proxmox cluster for my bigger installs. Most of my clients use 3 to 5 apps.

@ekevu123 I explained badly - was rushing - my bad. I meant that I test the new version with real data from production, so it can be repointed. But I don't often do staging, so I gladly defer to your workflow and your requirements. If your Feature Request is accepted and helps the flow, maybe I'll take the opportunity to learn from it. I'm distinctly low-tech long-route until I have learnt a smarter of doing it

@james hi thanks for the article - I have checked it and I can not understand how to force-upgrade-with-custom-manifest. Do I need to fork the app from your repo and build a completely custom app? My goal is to enable proxyAuth to the existing app that has some data and users.

FWIW, the docs repo is at https://git.cloudron.io/docs/docs/-/tree/master/knowledgebase/docs?ref_type=heads

I put in a text-align , https://git.cloudron.io/platform/box/-/commit/b2f5110871781f7e50fd440ffd2d211b1768770e

@joseph for some reason last night I never saw that screen. I checked for an update and there was an update button after that the backup started. Maybe it's a window size thing or my dark mode setting.. Unless we get 9.0.15 I won't be able to reproduce on my server. I can check the demo server if it's not updated yet.

@nebulon I just want to subscribe without log in first, it makes the process easier and shorter. @robi yes it can be, clickable qr code or qr code for payment to renewal.

This is fixed for the next release: https://git.cloudron.io/platform/box/-/commit/b5c75caea03a16aebcb761b9c60fbe71233c7936

So Cloudron really just displays what info is at /sys/devices/virtual/dmi/id/* so in your case To Be Filled By O.E.M. is probably set by the vendor intentionally or unintentionally. Our fallback is an empty string if the info file does not exist. Probably hard for us to distinguish between valid and non-valid strings here, if the vendor does put something.

So I am not sure what pangolin really needs here, but I did some more testing and the mentioned claims are all included in the JWT in my tests already in the currently released Cloudron OIDC server. How did you see that those aren't included in your case as you mentioned? Are you even getting a valid JWT and can you decode that? How does that json object look after that? The token response should look something like: { "access_token": "OGpFA1siYNbAQiCahuvjUDkKgoRAi4cz00lysJC6jt9", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFrRF..........", "refresh_token": "IJpU-ULmWoEYmUJmd55HLQF7aVHPbZIzdmWHUYQ1vB0", "scope": "openid profile email", "token_type": "Bearer" } Which then decoded in my case holds: Payload (Claims) sub: "nebulon" family_name: "" given_name: "Firstname" locale: "de-DE" name: "Lastname" preferred_username: "nebulon" picture: "https://my.cloudron/api/v1/profile/avatar/uid-e6e4afd0-f677-45e3-8d61-4dd039c32a11.png" email: "nebulon@..." email_verified: true aud: "cid-b901ffe1294a0683aff450bb86d036b5" exp: 1765189670 (8.12.2025, 11:27:50) iat: 1765186070 (8.12.2025, 10:27:50) iss: "https://my.cloudron..../openid"

Not sure if cloning is exactly UI-friendly here. The user intention is to add another domain, which is a separate action than cloning. You'd assume you perform an action that is separate from other domains, I'd say. For backup sites, I am more with you: There it makes more sense to use the same site, but change a detail.

But in this config there are with errors at cloudflare ( only one level at subdomains). But i see. Maybe you can bring it on the pipeline (without high priority). Greetings

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.

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.