Currently https://my.inference.coop/ is a Cloudron dashboard displaying a listing of Cloudron apps. This means we have very little flexibility in what we want displayed on the dashboard. For example, it might be more user-friendly to separate the "Docs and Code" button into "Docs" (linking to the docs README) and "Code" buttons, but this isn't possible with the current dashboard.
Why does it matter?
It would give us more flexibility in designing our dashboard, potentially making it more useful to users, especially new users who aren't familiar with all the different apps and resources.
Who is it for?
Anyone cool enough to be a member
How might it work?
Simple html site. Would be nice to pull in the app statuses (eg "Running") that are currently shown.
Anything else?
Any thoughts on the design/layout?
What changes to the dashboard would you like to see that become possible if we custom build it?
## What's the idea?
Currently https://my.inference.coop/ is a Cloudron dashboard displaying a listing of Cloudron apps. This means we have very little flexibility in what we want displayed on the dashboard. For example, it might be more user-friendly to separate the "Docs and Code" button into "Docs" (linking to the docs [README](https://git.inference.coop/co-op/docs/src/branch/main/README.md)) and "Code" buttons, but this isn't possible with the current dashboard.
## Why does it matter?
It would give us more flexibility in designing our dashboard, potentially making it more useful to users, especially new users who aren't familiar with all the different apps and resources.
## Who is it for?
Anyone cool enough to be a member
## How might it work?
Simple html site. Would be nice to pull in the app statuses (eg "Running") that are currently shown.
## Anything else?
Any thoughts on the design/layout?
What changes to the dashboard would you like to see that become possible if we custom build it?
Assessed this from the ops side — worth doing, with three guardrails:
The Cloudron dashboard is load-bearing beyond the launcher. It hosts the SSO session and the account surface members occasionally need (password changes, 2FA, sessions). First logins and password resets will still land there. So the play (as @ntnsndr suggests) is stop steering, don't remove: our dashboard becomes the home, with an explicit "Account settings" link to the Cloudron UI.
App statuses aren't free. Live "Running" states need a Cloudron API call with a scoped token — best done server-side via the portal (which already holds a read-only-capable token), not from the browser. Suggest v1 ships without statuses, then adds them through the portal.
Bonus: this layer survives infrastructure migrations. The Cloudron dashboard is vendor-specific; our own frontend carries across unchanged if/when we move hosts.
Net: no blocking downsides, and design/onboarding control is a real win. Suggest building on the existing member-dashboard app rather than a new one, so we're extending a surface we already secure and deploy.
Assessed this from the ops side — worth doing, with three guardrails:
- **The Cloudron dashboard is load-bearing beyond the launcher.** It hosts the SSO session and the account surface members occasionally need (password changes, 2FA, sessions). First logins and password resets will still land there. So the play (as @ntnsndr suggests) is *stop steering, don't remove*: our dashboard becomes the home, with an explicit "Account settings" link to the Cloudron UI.
- **App statuses aren't free.** Live "Running" states need a Cloudron API call with a scoped token — best done server-side via the portal (which already holds a read-only-capable token), not from the browser. Suggest v1 ships without statuses, then adds them through the portal.
- **Bonus: this layer survives infrastructure migrations.** The Cloudron dashboard is vendor-specific; our own frontend carries across unchanged if/when we move hosts.
Net: no blocking downsides, and design/onboarding control is a real win. Suggest building on the existing member-dashboard app rather than a new one, so we're extending a surface we already secure and deploy.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What's the idea?
Currently https://my.inference.coop/ is a Cloudron dashboard displaying a listing of Cloudron apps. This means we have very little flexibility in what we want displayed on the dashboard. For example, it might be more user-friendly to separate the "Docs and Code" button into "Docs" (linking to the docs README) and "Code" buttons, but this isn't possible with the current dashboard.
Why does it matter?
It would give us more flexibility in designing our dashboard, potentially making it more useful to users, especially new users who aren't familiar with all the different apps and resources.
Who is it for?
Anyone cool enough to be a member
How might it work?
Simple html site. Would be nice to pull in the app statuses (eg "Running") that are currently shown.
Anything else?
Any thoughts on the design/layout?
What changes to the dashboard would you like to see that become possible if we custom build it?
One thought is we could just build out dashboard.inference.coop to play this role, and no longer steer users toward the Cloudron interface.
Assessed this from the ops side — worth doing, with three guardrails:
Net: no blocking downsides, and design/onboarding control is a real win. Suggest building on the existing member-dashboard app rather than a new one, so we're extending a surface we already secure and deploy.