[deployer] Split the setup into two reusable building blocks: a Stack (services + release channel) and a Settings profile (keys, sender, message) #297

New issue

Open

opened 2026-06-17 03:23:10 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-06-17 03:23:10 +00:00

Owner

A Stack is a named list of services plus the release channel they install from (for example latest-main or latest-integration). It is just what runs and which build track. A stack carries nothing secret. Example: all services except Slides on the stable channel, saved as stack1.

A Settings profile is a named set of the configuration: which assistant providers are on, each provider key, the Resend key, the email sender (from address and from name), whether to send the welcome email, and the welcome message. Each key can either inherit the General (admin instance) default or hold the profile's own value, so a profile can keep the admin Resend key untouched while setting its own assistant key and a custom message. Example saved as settings1.

The Setups page becomes two clear sections, Stacks and Settings. You save a stack on its own, or a settings profile on its own. When creating or editing an organization you pick a Stack and a Settings profile (two separate pickers), and the organization can still set one-off overrides on top.

Secret handling keeps the rule we already enforce everywhere: a secret value is never duplicated. A Settings profile stores each of its own keys once, in the secret store, and organizations reference the profile rather than copying it. Duplicating a profile copies only the non-secret parts and resets the keys to inherit, so a copy never carries another profile's keys. Two organizations that pick the same profile share its keys (one source of truth); an organization that needs its own sets a per-organization override, which wins. The resolution order for any key or setting is: the organization's own override first, then its Settings profile, then the General default. A Stack or a Settings profile that a live organization uses cannot be deleted out from under it.

The current sample setups are throwaway test data, so there is no careful migration: they will be recreated as a stack plus a settings profile in the new shape.

Minor points to confirm during the build: keep the per-organization one-off override as the top tier (recommended, matches today) or drop it in favour of always picking a profile; and whether a Settings profile is optional on an organization (none selected means everything inherits General).

Today a setup bundles two different things in one object, which makes it unclear where a key lives. We want to replace it with two separate, named, reusable building blocks, and no combined object (a combined setup was considered and dropped, because it reintroduces the is-the-key-in-here confusion). A Stack is a named list of services plus the release channel they install from (for example latest-main or latest-integration). It is just what runs and which build track. A stack carries nothing secret. Example: all services except Slides on the stable channel, saved as stack1. A Settings profile is a named set of the configuration: which assistant providers are on, each provider key, the Resend key, the email sender (from address and from name), whether to send the welcome email, and the welcome message. Each key can either inherit the General (admin instance) default or hold the profile's own value, so a profile can keep the admin Resend key untouched while setting its own assistant key and a custom message. Example saved as settings1. The Setups page becomes two clear sections, Stacks and Settings. You save a stack on its own, or a settings profile on its own. When creating or editing an organization you pick a Stack and a Settings profile (two separate pickers), and the organization can still set one-off overrides on top. Secret handling keeps the rule we already enforce everywhere: a secret value is never duplicated. A Settings profile stores each of its own keys once, in the secret store, and organizations reference the profile rather than copying it. Duplicating a profile copies only the non-secret parts and resets the keys to inherit, so a copy never carries another profile's keys. Two organizations that pick the same profile share its keys (one source of truth); an organization that needs its own sets a per-organization override, which wins. The resolution order for any key or setting is: the organization's own override first, then its Settings profile, then the General default. A Stack or a Settings profile that a live organization uses cannot be deleted out from under it. The current sample setups are throwaway test data, so there is no careful migration: they will be recreated as a stack plus a settings profile in the new shape. Minor points to confirm during the build: keep the per-organization one-off override as the top tier (recommended, matches today) or drop it in favour of always picking a profile; and whether a Settings profile is optional on an organization (none selected means everything inherits General).

mik-tf added the

platform

label

2026-06-17 03:23:10 +00:00

mik-tf changed title from ~~[deployer] Split a setup into a reusable named stack (services) and a named settings profile (keys, email)~~ to [deployer] Split the setup into two reusable building blocks: a Stack (services + release channel) and a Settings profile (keys, sender, message)

2026-06-17 03:37:59 +00:00