Evaluate web UIs for our config commons #681

New Issue

2025-10-08T14:41:01Z

decentral1se commented

2025-10-08 14:41:01 +00:00

Please post your candidates! We can organise ourselves to push this forward.

Many many people would benefit from having a web UI and it would be a big victory for your config commons approach.

Please post your candidates! We can organise ourselves to push this forward. Many many people would benefit from having a web UI and it would be a big victory for your config commons approach. /cc @3wordchant

marlon commented

2025-10-08 15:35:27 +00:00

We don't have anything to show yet but just dropping a note to say that MIR has been planning to work on developing a web UI. So far all we have built is this design doc:

Abra WebUI Design Proposal

Background

Co-op Cloud is a framework for managing dockerized web services. The framework allows specifying many different services as recipes in a way that makes them easy to manage through a standardized workflow.

abra is a command line tool which is used to manage Co-op Cloud services. It is maintained by the Co-op Cloud project, and is effectively the core of the Co-op Cloud ecosystem.

Goal

Create a web application which allows users to do the following:

Deploy a new app from a recipe
Review currently running apps and their status
Perform common maintenance operations on deployments like upgrading, configuring, etc

Requirements

The web application should:

Operate primarily as a wrapper for abra, and not duplicate or re-implement its features
Allow abra to be used from the CLI or the webUI interchangeably without losing state or context information
Be deployable as a Co-op Cloud service
Be fully browser-based, not requiring any additional client-side software
Be secure against unauthorized access

Stretch Goals

Possibilities for development beyond MVP

Support browsing recipes, and displaying recipe documentation contextually
Automatically perform standard initial server setup (install Docker, etc)
Provision servers on demand using OpenTF providers or similar
Manage git operations required to keep the abra config synced across multiple abra clients

Technical Notes

abra has an option ( -m) which provides all output as json. This could be parsed by the webUI.
To run abra, the web application backend must hold SSH keys for each Co-op Cloud server. This is a security risk.

Interface Sketch

Dashboard
- Displays the output of `abra app ls`
- A button runs `abra app ls -S` to update the dashboard with information on versions, deploy status, etc
- Flags the following conditions with icons
  - Secrets are required but haven't been generated (link to Secrets)
  - App has an available upgrade (link to Upgrade App)
- Links to other function interfaces
New App
- Guided wizard for running `abra app new`
- Prompts for
  - server
  - app name
  - version (optional)
- Flows into Configure and Generate Secrets
Servers
- Displays output of `abra server ls`
- Allows creating and removing servers
- Creating a server prompts for
  - Hostname
  - Port (if not default)
  - Username
  - SSH keys (pub and priv)
App Specific Functions
- Configure App
  - Text-editor interface for modifying the config file ala `abra app config`
  - Flows into undeploy and redeploy app
- Deploy/Undeploy App
  - Runs `abra app deploy` and/or `abra app undeploy`
  - Displays output from abra
- Upgrade App
  - Displays current version and newer available versions
  - Displays upgrade notes contextually
  - Allows running `abra app upgrade`
  - Displays output from abra
- Secrets
  - Runs `abra app secrets` commands
  - Displays output of `abra app secrets list` for a service
  - Prompts for
    - Name of secret to generate (or all secrets)
  - Displays secret output from abra
- Logs
  - Runs `abra app logs` and displays the output in realtime
- Command
  - Runs `abra app command`
  - Lists available commands for the app
  - Optionally run commands
    - Prompts for arguments (generically, we don't know the expected structure of arguments)

Questions/Ideas

Make the MVP only manage the local server it's running on, avoiding the need to configure&manage SSH keys?

We don't have anything to show yet but just dropping a note to say that MIR has been planning to work on developing a web UI. So far all we have built is this design doc: # Abra WebUI Design Proposal ## Background Co-op Cloud is a framework for managing dockerized web services. The framework allows specifying many different services as _recipes_ in a way that makes them easy to manage through a standardized workflow. abra is a command line tool which is used to manage Co-op Cloud services. It is maintained by the Co-op Cloud project, and is effectively the core of the Co-op Cloud ecosystem. ## Goal Create a web application which allows users to do the following: * Deploy a new app from a recipe * Review currently running apps and their status * Perform common maintenance operations on deployments like upgrading, configuring, etc ## Requirements The web application should: * Operate primarily as a wrapper for abra, and not duplicate or re-implement its features * Allow abra to be used from the CLI or the webUI interchangeably without losing state or context information * Be deployable as a Co-op Cloud service * Be fully browser-based, not requiring any additional client-side software * Be secure against unauthorized access ## Stretch Goals Possibilities for development beyond MVP * Support browsing recipes, and displaying recipe documentation contextually * Automatically perform standard initial server setup (install Docker, etc) * Provision servers on demand using OpenTF providers or similar * Manage git operations required to keep the abra config synced across multiple abra clients ## Technical Notes * abra has an option ( -m) which provides all output as json. This could be parsed by the webUI. * To run abra, the web application backend must hold SSH keys for each Co-op Cloud server. This is a security risk. ## Interface Sketch * Dashboard * Displays the output of \`abra app ls\` * A button runs \`abra app ls -S\` to update the dashboard with information on versions, deploy status, etc * Flags the following conditions with icons * Secrets are required but haven't been generated (link to Secrets) * App has an available upgrade (link to Upgrade App) * Links to other function interfaces * New App * Guided wizard for running \`abra app new\` * Prompts for * server * app name * version (optional) * Flows into Configure and Generate Secrets * Servers * Displays output of \`abra server ls\` * Allows creating and removing servers * Creating a server prompts for * Hostname * Port (if not default) * Username * SSH keys (pub and priv) * App Specific Functions * Configure App * Text-editor interface for modifying the config file ala \`abra app config\` * Flows into undeploy and redeploy app * Deploy/Undeploy App * Runs \`abra app deploy\` and/or \`abra app undeploy\` * Displays output from abra * Upgrade App * Displays current version and newer available versions * Displays upgrade notes contextually * Allows running \`abra app upgrade\` * Displays output from abra * Secrets * Runs \`abra app secrets\` commands * Displays output of \`abra app secrets list\` for a service * Prompts for * Name of secret to generate (or all secrets) * Displays secret output from abra * Logs * Runs \`abra app logs\` and displays the output in realtime * Command * Runs \`abra app command\` * Lists available commands for the app * Optionally run commands * Prompts for arguments (generically, we don't know the expected structure of arguments) ## Questions/Ideas * Make the MVP only manage the local server it's running on, avoiding the need to configure&manage SSH keys?

decentral1se commented

2025-10-09 09:24:31 +00:00

Awesome @marlon, thanks! I will add one note here for implementors who don't want to re-implement abra but also would like to get a bit closer to the metal than what -m offers. We do provide a public API: https://docs.coopcloud.tech/abra/hack/#using-the-abra-public-api This means that if you wrote the web app in golang (e.g. GOTTH stack), you could consume the API directly and have a very fine grained level of control over what can be done. This would also mean that the web hackers also start contributing to abra (while still maintaining their own web UI codebase), which would make us also more resilient. This is something for consideration!

PS. I also think this might make the web UI self-bootstrap-able because you just have to download a binary to your server (like the abra installer script) and it can get you docker / traefik / etc. wired up automagically from there. So you could be doing a sort of curl https://install.<name-for-web-ui>.coopcloud.tech | bash -s -- --bootstrap or something?

Awesome @marlon, thanks! I will add one note here for implementors who don't want to re-implement `abra` but also would like to get a bit closer to the metal than what `-m` offers. We do provide a public API: https://docs.coopcloud.tech/abra/hack/#using-the-abra-public-api This means that if you wrote the web app in golang (e.g. [GOTTH](https://github.com/TomDoesTech/GOTTH) stack), you could consume the API directly and have a very fine grained level of control over what can be done. This would also mean that the web hackers also start contributing to `abra` (while still maintaining their own web UI codebase), which would make us also more resilient. This is something for consideration! PS. I also think this might make the web UI self-bootstrap-able because you just have to download a binary to your server (like the `abra` installer script) and it can get you docker / traefik / etc. wired up automagically from there. So you could be doing a sort of `curl https://install.<name-for-web-ui>.coopcloud.tech | bash -s -- --bootstrap` or something?

❤️ 1

simon commented

2025-10-09 12:17:30 +00:00

https://komo.do/

❤️ 2

stevensting commented

2025-10-09 12:57:52 +00:00

List of Competitor/Comrade UIs created during kite flying

List of Competitor/Comrade UIs created during kite flying - https://komo.do/ - https://en.docs.maadix.net/ - https://coolify.io/ - https://dokploy.com/ - https://cosmos-cloud.io/ - https://devpu.sh/ - https://caprover.com/ - https://dokku.com/ - only CLI - https://piku.github.io/ - only CLI

❤️ 2

decentral1se added the help wanted label 2026-01-26 19:57:58 +00:00

decentral1se commented

2026-03-29 00:07:55 +00:00

komodo v2 supports swarm: https://komo.do/docs/swarm

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#681