[deployer] Edit an organization in one place: link it to a node group and set its own settings at create and edit #296

New issue

Open

opened 2026-06-17 01:58:58 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-06-17 01:58:58 +00:00

Owner

Right now an organization is composed and managed across a few places, and two things are missing.

First, when you deploy an organization you can pick an infrastructure group (where its members run), but that choice is not stored on the organization: it is only used at that moment, so the Edit screen cannot show or change where an organization runs, and a later update or an added member does not reuse the group. Second, an organization's own settings (its own assistant keys, its own sender address, for example to bring your own Kimi key) can only be set after the organization exists, not when you create it.

Vocabulary we are standardizing on: a stack is the list of services; settings are the operational configuration (release channel, which assistant providers are on, welcome email, and the secret values: keys and sender address); a setup is a stack plus its non-secret settings. Settings exist as a General default on this admin instance and as a per-organization override. For security a setup never stores secret values: the keys and sender live in Settings (General default or per-organization override), so a setup stays safe to duplicate and reuse. We are also renaming the per-organization "configs" wording to "Settings" everywhere for clarity.

Concretely:

Persist an organization's infrastructure group on the organization, set it at deploy and change it in Edit, and reuse it on later updates and added members.
Let an organization set its own settings (its own keys and sender, blank inherits the General default) when you create it, not only afterward.
Bring it all together into one Edit organization screen: the name, the setup (stack plus settings) it runs, where it runs (its node group), and its own settings, all in one place. This is simpler and more organized than separate Edit and Settings dialogs.

This continues the Launcher work (#291) and the in-place organization editing from #295 .

Out of scope here and tracked separately: per-network grid wallets and the mnemonic on the General Settings page, and as a per-organization override, which is a larger change (#294).

Right now an organization is composed and managed across a few places, and two things are missing. First, when you deploy an organization you can pick an infrastructure group (where its members run), but that choice is not stored on the organization: it is only used at that moment, so the Edit screen cannot show or change where an organization runs, and a later update or an added member does not reuse the group. Second, an organization's own settings (its own assistant keys, its own sender address, for example to bring your own Kimi key) can only be set after the organization exists, not when you create it. Vocabulary we are standardizing on: a stack is the list of services; settings are the operational configuration (release channel, which assistant providers are on, welcome email, and the secret values: keys and sender address); a setup is a stack plus its non-secret settings. Settings exist as a General default on this admin instance and as a per-organization override. For security a setup never stores secret values: the keys and sender live in Settings (General default or per-organization override), so a setup stays safe to duplicate and reuse. We are also renaming the per-organization "configs" wording to "Settings" everywhere for clarity. Concretely: - Persist an organization's infrastructure group on the organization, set it at deploy and change it in Edit, and reuse it on later updates and added members. - Let an organization set its own settings (its own keys and sender, blank inherits the General default) when you create it, not only afterward. - Bring it all together into one Edit organization screen: the name, the setup (stack plus settings) it runs, where it runs (its node group), and its own settings, all in one place. This is simpler and more organized than separate Edit and Settings dialogs. This continues the Launcher work (https://forge.ourworld.tf/lhumina_code/home/issues/291) and the in-place organization editing from https://forge.ourworld.tf/lhumina_code/home/issues/295 . Out of scope here and tracked separately: per-network grid wallets and the mnemonic on the General Settings page, and as a per-organization override, which is a larger change (https://forge.ourworld.tf/lhumina_code/home/issues/294).

mik-tf commented

2026-06-17 02:17:29 +00:00

Author

Owner

Secret model confirmed (the middle way). The "secrets in the setup or not" question reduces to one hard rule plus a framing choice:

Hard rule: a secret value (an assistant key, the Resend key, the sender address, and later a wallet mnemonic) lives in exactly one place, the secret store, scoped to either General (the admin default) or one organization. It is never stored in the setup record, and it is never copied when a setup is duplicated or reused as a template. The reason is the clone: each organization owns a setup and you duplicate one to fork a variant for another organization, so a duplicate that carried the first organization's key would make the second one spend on it.

Framing: secrets belong to the organization, not to the setup, but the UI binds them so you set one thing. The setup stays a value-free, reusable recipe (stack plus the non-secret choices); the organization's own keys and sender are shown alongside it in the single Edit organization screen and are stored on the organization. Duplicating a setup copies the recipe and which providers are on, never a value, so a forked organization inherits the General default until it sets its own.

Every key has three labelled tiers: inherit the General default, the organization's own (bring your own, set here), or the member's own (replaced later in their Cockpit). Each field shows which tier is active.

Secret model confirmed (the middle way). The "secrets in the setup or not" question reduces to one hard rule plus a framing choice: Hard rule: a secret value (an assistant key, the Resend key, the sender address, and later a wallet mnemonic) lives in exactly one place, the secret store, scoped to either General (the admin default) or one organization. It is never stored in the setup record, and it is never copied when a setup is duplicated or reused as a template. The reason is the clone: each organization owns a setup and you duplicate one to fork a variant for another organization, so a duplicate that carried the first organization's key would make the second one spend on it. Framing: secrets belong to the organization, not to the setup, but the UI binds them so you set one thing. The setup stays a value-free, reusable recipe (stack plus the non-secret choices); the organization's own keys and sender are shown alongside it in the single Edit organization screen and are stored on the organization. Duplicating a setup copies the recipe and which providers are on, never a value, so a forked organization inherits the General default until it sets its own. Every key has three labelled tiers: inherit the General default, the organization's own (bring your own, set here), or the member's own (replaced later in their Cockpit). Each field shows which tier is active.