[deployer] Launcher: compose setups, members, and organizations into deployments

mik-tf commented

2026-06-16 05:58:55 +00:00

Owner

The deployer admin grew feature by feature and sprawled. This issue is the agreed plan to organize it into one clear hub, the Launcher, with the whole operator journey on one page of sketches so we plan it first and then build it. The database and backend already exist for most of this; the work is the UI and UX organization. We build in stages so no session is overloaded.

The model (layered, every layer has built-in defaults and is savable)

Stack: which apps a member instance runs. Built-in presets Core, Default, Full, plus custom variations.
Configs: the operational settings on top of a stack: release channel, assistant keys, welcome email.
Setup: a stack plus its configs. Named, saved, editable.
Infrastructure: where members run. The raw nodes (managed + found on the grid) and named node groups.
Member: one person: username, optional display name, email. Existing Forge account or new.
Organization: members plus a setup plus a node group, with its own settings (its keys, email, wallets), deployed and managed as one unit. Every member is in exactly one organization (a standalone person is a one member organization; ad hoc deployments land in the default organization).
General Settings: the admin instance defaults (keys, email, per network wallets) that every organization inherits unless it overrides them.

The Launcher

Top navigation keeps only the Launcher for provisioning (the Nodes page folds into the Launcher). Sidebar in build order:

Launcher
  Infrastructure   where members run
  Setups           what members run
  Organizations    who, plus deploy and manage  (the default landing)

Infrastructure (the Nodes page moves in, plus grouping)

Three sub views. Managed Nodes and Add Nodes are today's nodes page relocated as is; Group Nodes is the only new build.

[ Managed Nodes ] [ Add Nodes ] [ Group Nodes ]

Managed Nodes   the nodes you manage: id, farm, network, dedicated or shared, status, capacity, retire / unregister
Add Nodes       the current find nodes: filter by network, farm, country, rentable or dedicated, then register or rent
Group Nodes     named pools: "GroupA = farm 1 plus nodes 45 and 56 on mainnet"; a group is picked as the where in Deploy

Setups (stack plus configs, with edit)

Saved setups:   each with Edit, Use in a deployment, Delete
Build or edit a setup:
  STACK (which apps)   Core / Default / Full, then the app checkboxes
  CONFIGS              release channel, assistant keys, welcome email
  Name, then Save  (Edit loads a saved setup back into the builder to modify and re save)

Organizations (deploy and manage)

Organizations                         [ Update all organizations ]  [ + New organization ]

  Acme (10)            [ Settings ]  [ Update all instances ]  [ + Add a member ]
    member rows: username, display name, instance, cockpit, actions
    select members for a batch action

Deploy  (revealed by New organization or Add a member)
  Who     member rows, one for a single member or many; each existing or new, with optional name and email
  Org     an existing organization, or a new one
  Setup   Core / Default / Full, or a saved setup
  Where   Auto, or a node group
  Deploy

Deploy and update work at three granularities: a single member, a selected batch, or a whole organization.

Settings: general defaults, overridden per organization

The Settings page holds General Settings only: the admin instance defaults (Resend key, email sender, per network wallets, assistant keys).
Each organization has its own settings (a panel on the organization, set at create time or later): its Resend key, email, per network wallets, assistant keys. Blank inherits the General default. So Acme can send from its own address with its own keys and its own mainnet and qanet wallets.
The settings live on the organization (the one place to set them); General is the fallback. The username and one time password block of the welcome email stays system owned and is never part of any custom template.

Cross cutting

Confirmations (update all, deletes) use an in app modal, not the browser dialog.
Batch actions via row selection.

Build stages (smallest risk first; the backend largely exists)

Setups: the stack and configs split, the Core / Default / Full presets, and editing a saved setup.
Settings: General Settings, and per organization settings on the organization (Resend key, email, per network wallets, assistant keys, inheriting General).
Infrastructure: relocate the nodes page into Managed Nodes and Add Nodes, then build Group Nodes and the group picker in Deploy, with a whole organization capacity check.
Polish: in app modal confirmations and batch update.

Definition of done

An operator opens the Launcher and has one place for everything. They build a node group and a setup (a stack of apps plus configs), then deploy: choose who (members), which organization (existing or new), what (a setup), and where (a node group or auto). Every member is created behind its own login, inside an organization. Each organization is managed as a unit (see members, update all instances, add members) and carries its own settings (keys, email, per network wallets), falling back to the General defaults. A single person is just a one member organization.

Tracked under #285.

The deployer admin grew feature by feature and sprawled. This issue is the agreed plan to organize it into one clear hub, the Launcher, with the whole operator journey on one page of sketches so we plan it first and then build it. The database and backend already exist for most of this; the work is the UI and UX organization. We build in stages so no session is overloaded. ## The model (layered, every layer has built-in defaults and is savable) - **Stack**: which apps a member instance runs. Built-in presets **Core**, **Default**, **Full**, plus custom variations. - **Configs**: the operational settings on top of a stack: release channel, assistant keys, welcome email. - **Setup**: a stack plus its configs. Named, saved, editable. - **Infrastructure**: where members run. The raw nodes (managed + found on the grid) and named **node groups**. - **Member**: one person: username, optional display name, email. Existing Forge account or new. - **Organization**: members plus a setup plus a node group, with its own **settings** (its keys, email, wallets), deployed and managed as one unit. Every member is in exactly one organization (a standalone person is a one member organization; ad hoc deployments land in the default organization). - **General Settings**: the admin instance defaults (keys, email, per network wallets) that every organization inherits unless it overrides them. ## The Launcher Top navigation keeps only the Launcher for provisioning (the Nodes page folds into the Launcher). Sidebar in build order: ``` Launcher Infrastructure where members run Setups what members run Organizations who, plus deploy and manage (the default landing) ``` ## Infrastructure (the Nodes page moves in, plus grouping) Three sub views. Managed Nodes and Add Nodes are today's nodes page relocated as is; Group Nodes is the only new build. ``` [ Managed Nodes ] [ Add Nodes ] [ Group Nodes ] Managed Nodes the nodes you manage: id, farm, network, dedicated or shared, status, capacity, retire / unregister Add Nodes the current find nodes: filter by network, farm, country, rentable or dedicated, then register or rent Group Nodes named pools: "GroupA = farm 1 plus nodes 45 and 56 on mainnet"; a group is picked as the where in Deploy ``` ## Setups (stack plus configs, with edit) ``` Saved setups: each with Edit, Use in a deployment, Delete Build or edit a setup: STACK (which apps) Core / Default / Full, then the app checkboxes CONFIGS release channel, assistant keys, welcome email Name, then Save (Edit loads a saved setup back into the builder to modify and re save) ``` ## Organizations (deploy and manage) ``` Organizations [ Update all organizations ] [ + New organization ] Acme (10) [ Settings ] [ Update all instances ] [ + Add a member ] member rows: username, display name, instance, cockpit, actions select members for a batch action Deploy (revealed by New organization or Add a member) Who member rows, one for a single member or many; each existing or new, with optional name and email Org an existing organization, or a new one Setup Core / Default / Full, or a saved setup Where Auto, or a node group Deploy ``` Deploy and update work at three granularities: a single member, a selected batch, or a whole organization. ## Settings: general defaults, overridden per organization - The **Settings** page holds **General Settings** only: the admin instance defaults (Resend key, email sender, per network wallets, assistant keys). - Each **organization** has its **own settings** (a panel on the organization, set at create time or later): its Resend key, email, per network wallets, assistant keys. Blank inherits the General default. So Acme can send from its own address with its own keys and its own mainnet and qanet wallets. - The settings live on the organization (the one place to set them); General is the fallback. The username and one time password block of the welcome email stays system owned and is never part of any custom template. ## Cross cutting - Confirmations (update all, deletes) use an in app modal, not the browser dialog. - Batch actions via row selection. ## Build stages (smallest risk first; the backend largely exists) 1. **Setups**: the stack and configs split, the Core / Default / Full presets, and editing a saved setup. 2. **Settings**: General Settings, and per organization settings on the organization (Resend key, email, per network wallets, assistant keys, inheriting General). 3. **Infrastructure**: relocate the nodes page into Managed Nodes and Add Nodes, then build Group Nodes and the group picker in Deploy, with a whole organization capacity check. 4. **Polish**: in app modal confirmations and batch update. ## Definition of done An operator opens the Launcher and has one place for everything. They build a node group and a setup (a stack of apps plus configs), then deploy: choose who (members), which organization (existing or new), what (a setup), and where (a node group or auto). Every member is created behind its own login, inside an organization. Each organization is managed as a unit (see members, update all instances, add members) and carries its own settings (keys, email, per network wallets), falling back to the General defaults. A single person is just a one member organization. Tracked under #285.