The bug is fixed now! But I still don't get the per-app overview. When I choose all apps and services, I still see the tops only. So, doable, sure, but maybe someone else wants this feature as well, so we can leave this open.

So currently the login flow pages are served up with content security policy headers to not allow being embedded in another domain/origin. The reason for this is to prevent clickjacking attacks and was explicitly done that way. I guess for this we would need a csp setting for the OpenID provider where one can allow specific domains/origins.

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 would also love to see this happening, hopefully we find some time soon to get it done.

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.